On 08/18/2009 09:41 AM, Arthur Dent wrote: > On Tue, 2009-08-18 at 13:48 +0200, Dominick Grift wrote: >> On Tue, Aug 18, 2009 at 12:23:25PM +0100, Arthur Dent wrote: >>> On Tue, 2009-08-18 at 12:46 +0200, Dominick Grift wrote: >>>> On Tue, Aug 18, 2009 at 11:39:07AM +0100, Arthur Dent wrote: >>>>> On Tue, 2009-08-18 at 11:21 +0200, Dominick Grift wrote: >>>>>> On Tue, Aug 18, 2009 at 10:12:16AM +0100, Arthur Dent wrote: >>>>>>> On Sat, 2009-08-15 at 11:50 +0100, Arthur Dent wrote: >>>>> >>>>> [snip] >>>>> >>>>>>> >>>>>>> Just to add to my own mail... >>>>>>> >>>>>>> I employed the above policy module, everything seemed OK so (as this >>>>>>> seemed to be the last of the problems since upgrading) I switched to >>>>>>> enforcing mode. >>>>>>> >>>>>>> Since doing so I have received no AVCs but I am finding these in my >>>>>>> maillog: >>>>>>> >>>>>>> procmail: Lock failure on "/mnt/backup/mail/rawmail.lock" >>>>>>> procmail: Error while writing to "/mnt/backup/mail/rawmail" >>>>>>> >>>>>>> Temporarily switching back with setenforce 0 stops them so it is selinux >>>>>>> related... > [snip] >>>>>>> But still no AVCs >>>>>>> >>>>>>> Any ideas? >>>>>> Try semodule -DB to unload any silent denials. Remember that the denials shown after you do this are meant to be silenced. >>>>>> To reload policy with the silenced denials: semodule -B. >>>>>> >>>>>> Also keep an eye on /var/log/messages since the DBUS user space object manager logs some denials there (if DBUS is at all involved) >>>>> >>>>> OK - since semodule -DB getting flooded with AVCs... >>>>> >>>>> Here are some that are related to this problem... >>>>> >>>>> cat /var/log/audit/audit.log | grep -i procmail >>>>> .... >>>>> type=AVC msg=audit(1250591203.244:43494): avc: denied { rlimitinh } >>>>> for pid=14767 comm="procmail" scontext=system_u:system_r:sendmail_t:s0 >>>>> tcontext=system_u:system_r:procmail_t:s0 tclass=process >>>>> type=AVC msg=audit(1250591203.244:43494): avc: denied { siginh } for >>>>> pid=14767 comm="procmail" scontext=system_u:system_r:sendmail_t:s0 >>>>> tcontext=system_u:system_r:procmail_t:s0 tclass=process >>>>> type=AVC msg=audit(1250591203.244:43494): avc: denied { noatsecure } >>>>> for pid=14767 comm="procmail" scontext=system_u:system_r:sendmail_t:s0 >>>>> tcontext=system_u:system_r:procmail_t:s0 tclass=process >>>>> type=SYSCALL msg=audit(1250591203.244:43494): arch=40000003 syscall=11 >>>>> success=yes exit=0 a0=5d8098 a1=bf83277c a2=4ab960 a3=41904 items=0 >>>>> ppid=14766 pid=14767 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 >>>>> egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="procmail" >>>>> exe="/usr/bin/procmail" subj=system_u:system_r:procmail_t:s0 key=(null) >>>>> type=AVC msg=audit(1250591203.418:43495): avc: denied { search } for >>>>> pid=14767 comm="procmail" name="mnt" dev=sda5 ino=943921 >>>>> scontext=system_u:system_r:procmail_t:s0 >>>>> tcontext=system_u:object_r:mnt_t:s0 tclass=dir >>>>> type=SYSCALL msg=audit(1250591203.418:43495): arch=40000003 syscall=196 >>>>> success=no exit=-2 a0=9779280 a1=bf95f790 a2=77cff4 a3=97793f8 items=0 >>>>> ppid=14766 pid=14767 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 >>>>> egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="procmail" >>>>> exe="/usr/bin/procmail" subj=system_u:system_r:procmail_t:s0 key=(null) >>>>> >>>>> This still with setenforce 0 >>>>> >>>>> Any ideas? >>>>> >>>>> Thanks for your help!... >>>>> >>>>> Mark >>>>> >>>> >>>> The only AVC denial that is ( a little bit ) interesting is: >>>> >>>> avc: denied { search } for >>>> pid=14767 comm="procmail" name="mnt" dev=sda5 ino=943921 >>>> scontext=system_u:system_r:procmail_t:s0 >>>> tcontext=system_u:object_r:mnt_t:s0 tclass=dir >>>> >>>> Pipe this into audit2why to see if it has any suggestions. Although i doubt it is related to your issue. >>>> >>>> A quick way to rule out SELinux as the cause of your issue is to reproduce the issue in permissive mode. >>>> >>>> If access is (still) denied when you try to reproduce it in permissive mode, than it is not an SELinux issue. >>>> >>>> If it works in permissive mode, but not in enforcing mode, then it is a SELinux issue. >>>> >>> >>> Well all that audit2why suggests for that avc is: >>> >>> Was caused by: >>> Missing type enforcement (TE) allow rule. >>> >>> You can use audit2allow to generate a loadable module to allow this >>> access. >>> >>> On your other point, you will notice (further up in this mail) that this >>> problem is only in Enforcing mode. Switching to Permissive does indeed >>> stop the procmail errors. >>> >>> Still watching the avcs.... I'll keep you posted.. >>> >>> Thanks >>> >>> Mark >>> >> >> Whoops obviously you need to allow procmail_t to search mountpoints to make it work. >> >> echo "> > avc: denied { search } for pid=14767 comm="procmail" name="mnt" dev=sda5 ino=943921 scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:mnt_t:s0 tclass=dir" auditallow -M myprocmail; semodule -i myprocmail.pp >> >> this is a bug in policy > > Thank you Dominick, that's fixed it! > > I had already created a policy module from that AVC just to see what it > would look like - but I hadn't implemented it. Now I have and it works > fine! > > BTW, I though your way of creating the module was very clever - I liked > that.. but for the sake of the archives there are a couple of typos: > > echo "> > avc: denied { search } for pid=14767 comm="procmail" > name="mnt" dev=sda5 ino=943921 scontext=system_u:system_r:procmail_t:s0 > tcontext=system_u:object_r:mnt_t:s0 tclass=dir" auditallow -M > ^^^ ^^^ > myprocmail; semodule -i myprocmail.pp > > Should be: > echo "> > avc: denied { search } for pid=14767 comm="procmail" > name="mnt" dev=sda5 ino=943921 scontext=system_u:system_r:procmail_t:s0 > tcontext=system_u:object_r:mnt_t:s0 tclass=dir" | audit2allow -M > myprocmail; semodule -i myprocmail.pp > > Thanks again > > Your help is much appreciated! > > Mark > > > > ------------------------------------------------------------------------ > > -- > fedora-selinux-list mailing list > fedora-selinux-list@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/fedora-selinux-list I will change rawhide to allow all domains to search mnt_t, since this is a logical place for people to mount directories that a confined application might need access to. Similarly I will allow all domains to search default_t, which is the default name for a directory created in / -- fedora-selinux-list mailing list fedora-selinux-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-selinux-list