On Sat, 2009-07-11 at 22:30 +0200, Dominick Grift wrote:
> 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
Actually my solution might not work after all unfortunately. So i guess
either label it lib_t manually or give spamd_t execute access to
spamd_var_lib_t...
>
> > Sincerely yours,
> > Vadym Chepkov
> >
> >
> > --- On Sat, 7/11/09, Dominick Grift <domg472@xxxxxxxxx> wrote:
> >
> > > From: Dominick Grift <domg472@xxxxxxxxx>
> > > Subject: Re: spamassassin pre-compiled rules
> > > To: "Vadym Chepkov" <chepkov@xxxxxxxxx>
> > > Cc: "Fedora SELinux" <fedora-selinux-list@xxxxxxxxxx>
> > > 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@xxxxxxxxxx
> > > > https://www.redhat.com/mailman/listinfo/fedora-selinux-list
> > >
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-selinux-list mailing list fedora-selinux-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-selinux-list
