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...
> > > > >
> > > > >
> > > > > Also, I get these dovecot messages (although I haven't investigated
> > > > > fully if they are selinux related...
> > > > > **Unmatched Entries**
> > > > > dovecot: IMAP(wife): fchown() failed with
> > > > > file /home/wife/mail/.imap/INBOX/dovecot.index.tmp: Operation not
> > > > > permitted: 1 Time(s)
> > > > > dovecot: IMAP(son): fchown() failed with
> > > > > file /home/son/mail/.imap/INBOX/dovecot.index.cache.lock: Operation not
> > > > > permitted: 1 Time(s)
> > > > > dovecot: IMAP(son): fchown() failed with
> > > > > file /home/son/mail/.imap/INBOX/dovecot.index.log.newlock: Operation not
> > > > > permitted: 1 Time(s)
> > > > > dovecot: IMAP(son): fchown() failed with
> > > > > file /home/son/mail/.imap/INBOX/dovecot.index.tmp: Operation not
> > > > > permitted: 3 Time(s)
> > > > >
> > > > >
> > > > > 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
> --
> fedora-selinux-list mailing list
> fedora-selinux-list@xxxxxxxxxx
> https://www.redhat.com/mailman/listinfo/fedora-selinux-list
Attachment:
pgp2Q5yeWe0eY.pgp
Description: PGP signature
-- fedora-selinux-list mailing list fedora-selinux-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-selinux-list
