Created attachment 597433 [details]
ausearch for the dovecot violations

Description of problem:
Starting both chroot named and dovecot result in non-fatal audit violation

Version-Release number of selected component (if applicable):
selinux-policy-3.10.0-134

How reproducible:
Always

Steps to Reproduce:
1. Install named, configure and start using named-chroot.service
2. Install dovecot, configure and start using dovecot.service
3. Check audit2why -b
  
Actual results:
Series of audit2why -b results similar to:
type=AVC msg=audit(1341964065.237:476): avc:  denied  { search } for  pid=22364 comm="dovecot" name="named" dev="dm-2" ino=1572878 scontext=system_u:system_r:dovecot_t:s0 tcontext=system_u:object_r:named_zone_t:s0 tclass=dir

Expected results:
No audit output

Additional info:
The audit results appear to be the result of dovecot performing a stat on all the mounts in /etc/mtab.  Since named-chroot places mounts under /var/named/chroot... and /var/named is tagged named_zone_t, the stat call traverses the directory.  The stat call appears to succeed regardless (at least as reported in strace), so it's a non-fatal error that probably shouldn't be audited.

The following mounts are in /etc/mtab related to this issue:
/var/named/chroot/etc/named
/var/named/chroot/var/named
/var/named/chroot/etc/named.conf
/var/named/chroot/etc/named.rfc1912.zones
/var/named/chroot/etc/rndc.key
/var/named/chroot/lib{64}/bind
/var/named/chroot/etc/named.iscdlv.key
/var/named/chroot/etc/named.root.key

Probably the simplest solution is to just add:

dontaudit dovecot_t named_zone_t:dir search;

to the policy, that way people won't be concerned about a problem that isn't a security issue (and waste time tracking this down as I did :)