Re: spamassassin pre-compiled rules

On Sat, 2009-07-11 at 12:49 -0700, Vadym Chepkov wrote: > I figured it out. There is a proper label in the policy > > /var/lib/spamassassin/compiled/.*\.so.* regular file system_u:object_r:lib_t:s0 > > It seems when a script that compiles this library runs, it creates shared libraries with spamd_var_lib_t instead. So I guess the only way to fix this issue is to run restorecon -R /var/lib/spamassassin/compiled/ right after sa-compile finishes. The solution i described below makes spamd_t create files with a type it can execute. That does not require you to run restorecon. But if you do not mind to restore the context manually then lib_t might be a reasonable solution. Be aware though that all domains have access to lib_t

> Sincerely yours, > Vadym Chepkov > > > --- On Sat, 7/11/09, Dominick Grift <domg472(a)gmail.com&gt; wrote: > > > From: Dominick Grift <domg472(a)gmail.com&gt; > > Subject: Re: spamassassin pre-compiled rules > > To: "Vadym Chepkov" <chepkov(a)yahoo.com&gt; > > Cc: "Fedora SELinux" <fedora-selinux-list(a)redhat.com&gt; > > Date: Saturday, July 11, 2009, 12:38 PM > > On Sat, 2009-07-11 at 05:06 -0700, > > Vadym Chepkov wrote: > > > spamassassin rules got updated recently and I got this > > avc > > > > > > type=AVC msg=audit(1247216252.200:31900): avc: > > denied { execute } for pid=24001 comm="spamd" > > path="/var/lib/spamassassin/compiled/5.010/3.002005/auto/Mail/SpamAssassin/CompiledRegexps/body_0/body_0.so" > > dev=dm-3 ino=124989 scontext=system_u:system_r:spamd_t:s0 > > tcontext=system_u:object_r:spamd_var_lib_t:s0 tclass=file > > > > > > audit2allow suggests this > > > #============= spamd_t ============== > > > allow spamd_t spamd_var_lib_t:file execute; > > > seems reasonable, but why is it missing in standard > > policy? > > > > > > Sincerely yours, > > > Vadym Chepkov > > > > Is that file part of the package? > > /var/lib/spamassassin/compiled/5.010/3.002005/auto/Mail/SpamAssassin/CompiledRegexps/body_0/body_0.so > > > > It is probably created by spamd_t. > > > > The problem is that if you allow spamd_t to execute files > > with type > > spamd_var_lib_t then spamd_t can run everything > > in /var/lib/spamassassin. > > > > This is not so nice but it might not be a problem either > > > > Looking at the path it appears that spamd put compiled > > stuff > > under /var/lib/spamassassin/compiled/ > > > > assuming that all stuff under there should be executable by > > spamd_t, one > > could consider to introduce a new type for spamd_t > > executable files > > there. > > > > That would look something like this: > > > > myspamd.te: > > policy_module(myspamd, 0.0.1) > > type spamd_var_lib_exec_t; > > files_type(spamd_var_lib_exec_t) > > require { type spamd_t; } > > filetrans_pattern(spamd_t, spamd_var_lib_exec_t, > > spamd_var_lib_exec_t, > > { dir file }) > > manage_dirs_pattern(spamd_t, spamd_var_lib_exec_t, > > spamd_var_lib_exec_t) > > manage_files_pattern(spamd_t, spamd_var_lib_exec_t, > > spamd_var_lib_exec_t) > > exec_files_pattern(spamd_t, spamd_var_lib_exec_t, > > spamd_var_lib_exec_t) > > > > myspamd.fc: > > /var/lib/spamassassin/compiled(/.*)? -- > > gen_context(system_u:object_r:spamd_var_lib_exec_t, s0) > > > > But i guess that depends on your security requirements > > > > For now this could be considered a bug in selinux-policy > > > > > > > fedora-selinux-list mailing list > > > fedora-selinux-list(a)redhat.com > > > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > >