Bug 667579

Any idea why is dovecot-deliver trying to get information about the /var/lib/logcheck directory?

If you execute

# semanage permissive -a dovecot_deliver_t

do you get more AVC messages?

As far as I can see there is no reason for dovecot to access the logcheck directory. The bug should be Dovecot is trying to access the logcheck directory when it shouldn't be.

I have run the command after rebooting the server. The last error message was at 19:34 local, about an hour ago. I am now seeing entries for:
"SELinux is preventing /usr/libexec/postfix/local from search access on the directory /var/lib/logcheck. For complete SELinux messages. run sealert...."

sealert message is:

SELinux is preventing /usr/libexec/postfix/local from search access on the directory /var/lib/logcheck.

*****  Plugin catchall (100. confidence) suggests  ***************************

If you believe that local should be allowed search access on the logcheck directory by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep /usr/libexec/postfix/local /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

Again postfix should not be accessing the directory.

The only thing I can think of is that I have added the user logcheck to the root group to allow it access to the /var/log/messages and /var/log/audit log files. That was due to the install of logcheck not setting access for logcheck to the specified files.

Looks like it relates with your logcheck account.

Could you add your outputs of

# grep logcheck /etc/passwd

# doveconf -n

[root@icebox ~]# grep logcheck /etc/passwd
logcheck:x:482:467:Logcheck user:/var/lib/logcheck:/sbin/nologin
[root@icebox ~]# doveconf -n
# 2.0.8: /etc/dovecot/dovecot.conf
# OS: Linux 2.6.35.10-74.fc14.i686.PAE i686 Fedora release 14 (Laughlin)
mbox_write_locks = fcntl
passdb {
  driver = pam
}
ssl_cert = </etc/pki/dovecot/certs/dovecot.pem
ssl_key = </etc/pki/dovecot/private/dovecot.pem
userdb {
  driver = passwd
}
[root@icebox ~]# exit

[root@icebox ~]# grep logcheck /etc/passwd
logcheck:x:482:467:Logcheck user:/var/lib/logcheck:/sbin/nologin
[root@icebox ~]# doveconf -n
# 2.0.8: /etc/dovecot/dovecot.conf
# OS: Linux 2.6.35.10-74.fc14.i686.PAE i686 Fedora release 14 (Laughlin)
mbox_write_locks = fcntl
passdb {
  driver = pam
}
ssl_cert = </etc/pki/dovecot/certs/dovecot.pem
ssl_key = </etc/pki/dovecot/private/dovecot.pem
userdb {
  driver = passwd
}
[root@icebox ~]# exit

Ok, now it is clear. /var/lib/logcheck is home dir and dovecot-lda checks this home dir.

You can allow it using

# grep logwatch_cache_t /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

Of course! That make sense that Dovecot would be checking home directories for mail files. I will make the selinux policy as a work around while I check out the options in dovecot to exclude no login users from being checked for mail files.

If a vulnerablility was exploited in Dovecot, having selinux permissions to logcheck is probably not a really good idea. You don't have the same problem with Tripwire as it has no seperate user account.

The local policy will allow getattr on the directory. I do not want to allow dovecot-lda to read/write or manage logcheck/logwatch cache directories/files at all.

The exclude option looks good.

(In reply to comment #8)
> Of course! That make sense that Dovecot would be checking home directories for
> mail files. I will make the selinux policy as a work around while I check out
> the options in dovecot to exclude no login users from being checked for mail
> files.

btw, this won't work. dovecot does not try to check all users home dirs to find where is any mail box. It checks users directory *only* when it was asked to deliver email to that user and in that case it needs to check it. If you don't want this to happen: A)make sure no one sends email to that user, B)explicitly specify mail location so dovecot does not have to guess it

Did we solve this problem?

I believe the solution is described in the comment #10.