We've just built a new machine, running CentOS 6.4. I built, then my manager pulled stuff off the machine that it's replacing, installing as necessary. I'm seeing a ton of complaints of "SELinux is preventing /usr/libexec/dovecot/imap from search access on the directory indexes.". Now, ps -Z | grep dove shows that dovecot's running as unconfined_u:system_r:dovecot_t:s0, while a typical index it's trying to read shows ll -Z as system_u:object_r:dovecot_t. As a side note, it's owned by user, with group of nobody.
I see the same file on the old server as being system_u:object_r:var_spool_t.
Why would selinux be complaining? Is what was on the old system the correct context?
mark
On 04/22/2013 09:45 PM, m.roth@5-cent.us wrote:
We've just built a new machine, running CentOS 6.4. I built, then my manager pulled stuff off the machine that it's replacing, installing as necessary. I'm seeing a ton of complaints of "SELinux is preventing /usr/libexec/dovecot/imap from search access on the directory indexes.". Now, ps -Z | grep dove shows that dovecot's running as unconfined_u:system_r:dovecot_t:s0, while a typical index it's trying to read shows ll -Z as system_u:object_r:dovecot_t. As a side note, it's owned by user, with group of nobody.
I see the same file on the old server as being system_u:object_r:var_spool_t.
Why would selinux be complaining? Is what was on the old system the correct context?
mark
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
Could you attach AVC mgs? Probably missing SELinux policy/contexts.
Regards, Mirek
m.roth@5-cent.us wrote:
We've just built a new machine, running CentOS 6.4. I built, then my manager pulled stuff off the machine that it's replacing, installing as necessary. I'm seeing a ton of complaints of "SELinux is preventing /usr/libexec/dovecot/imap from search access on the directory indexes.". Now, ps -Z | grep dove shows that dovecot's running as unconfined_u:system_r:dovecot_t:s0, while a typical index it's trying to read shows ll -Z as system_u:object_r:dovecot_t. As a side note, it's owned by user, with group of nobody.
I see the same file on the old server as being system_u:object_r:var_spool_t.
Why would selinux be complaining? Is what was on the old system the correct context?
This is very frustrating. My manager rebooted this morning, so now I'm not sure about which avc I wrote about yesterday. However, I see various things: 1. Last night, dovecot was throwing AVCs... and I was looking at it mentioning one user's email spool... but when I ran the sealert, it spoke of a *different* user's spool.
Looking at a few of the AVCs, as Miroslav requested, *some* of this may have changed, even without a relabel on the reboot, since I see it complaining that something had been unlabled, where if I look at it now with ll -Z, I see it as dovecot_t.
2. Sendmail is complaining, among other things, that it can't write to /etc/sendmail/statistics. ll -Z shows -rw-r--r--. root root unconfined_u:object_r:etc_t:s0 statistics Meanwhile, I try to look at /usr/sbin/sendmail (ARGH!): lrwxrwxrwx. root root system_u:object_r:bin_t:s0 /usr/sbin/sendmail -> /etc/alternatives/mta lrwxrwxrwx. root root system_u:object_r:etc_t:s0 /etc/alternatives/mta -> /usr/sbin/sendmail.sendmail -rwxr-sr-x. root smmsp system_u:object_r:sendmail_exec_t:s0 /usr/sbin/sendmail.sendmail Looking further in my log, I see it's also complaining about sendmail trying to do things to /var/run/milter-greylist/milter-greylist.sock. So, can someone suggest what I need to do to make selinux shut up about sendmail? Typical AVC: type=AVC msg=audit(1366726917.008:87837): avc: denied { write } for pid=1401 comm="sendmail" name="statistics" dev=sda3 ino=44769294 scontext=system_u:system_r:sendmail_t:s0 tcontext=unconfined_u:object_r:etc_t:s0 tclass=file
Is this telling me that, as I asked yesterday, I need to change the user context to system_u from unconfined_u?
3. This one makes *zero* sense to me: SELinux is preventing /lib64/security/pam_krb5/pam_krb5_storetmp from execute access on the file /lib64/security/pam_krb5/pam_krb5_storetmp. ll -Z -rwxr-xr-x. root root system_u:object_r:bin_t:s0 /lib64/security/pam_krb5/pam_krb5_storetmp*
I won't even start to get into the perl complaints....
mark
On 04/23/2013 04:37 PM, m.roth@5-cent.us wrote:
m.roth@5-cent.us wrote:
We've just built a new machine, running CentOS 6.4. I built, then my manager pulled stuff off the machine that it's replacing, installing as necessary. I'm seeing a ton of complaints of "SELinux is preventing /usr/libexec/dovecot/imap from search access on the directory indexes.". Now, ps -Z | grep dove shows that dovecot's running as unconfined_u:system_r:dovecot_t:s0, while a typical index it's trying to read shows ll -Z as system_u:object_r:dovecot_t. As a side note, it's owned by user, with group of nobody.
I see the same file on the old server as being system_u:object_r:var_spool_t.
Why would selinux be complaining? Is what was on the old system the correct context?
This is very frustrating. My manager rebooted this morning, so now I'm not sure about which avc I wrote about yesterday. However, I see various things:
- Last night, dovecot was throwing AVCs... and I was looking at it
mentioning one user's email spool... but when I ran the sealert, it spoke of a *different* user's spool.
Looking at a few of the AVCs, as Miroslav requested, *some* of this
may have changed, even without a relabel on the reboot, since I see it complaining that something had been unlabled, where if I look at it now with ll -Z, I see it as dovecot_t.
- Sendmail is complaining, among other things, that it can't write to /etc/sendmail/statistics. ll -Z shows -rw-r--r--. root root unconfined_u:object_r:etc_t:s0 statistics Meanwhile, I try to look at /usr/sbin/sendmail (ARGH!):
lrwxrwxrwx. root root system_u:object_r:bin_t:s0 /usr/sbin/sendmail -> /etc/alternatives/mta lrwxrwxrwx. root root system_u:object_r:etc_t:s0 /etc/alternatives/mta -> /usr/sbin/sendmail.sendmail -rwxr-sr-x. root smmsp system_u:object_r:sendmail_exec_t:s0 /usr/sbin/sendmail.sendmail Looking further in my log, I see it's also complaining about sendmail trying to do things to /var/run/milter-greylist/milter-greylist.sock. So, can someone suggest what I need to do to make selinux shut up about sendmail? Typical AVC: type=AVC msg=audit(1366726917.008:87837): avc: denied { write } for pid=1401 comm="sendmail" name="statistics" dev=sda3 ino=44769294 scontext=system_u:system_r:sendmail_t:s0 tcontext=unconfined_u:object_r:etc_t:s0 tclass=file
Is this telling me that, as I asked yesterday, I need to change the
user context to system_u from unconfined_u?
3. This one makes *zero* sense to me: SELinux is preventing
/lib64/security/pam_krb5/pam_krb5_storetmp from execute access on the file /lib64/security/pam_krb5/pam_krb5_storetmp. ll -Z -rwxr-xr-x. root root system_u:object_r:bin_t:s0 /lib64/security/pam_krb5/pam_krb5_storetmp*
I won't even start to get into the perl complaints.... mark
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
Ok, hard to say without AVC msgs. But for the first issue
milter_stream_connect_all(sendmail_t)
Then the problem is with
/etc/sendmail/statistics
which is supposed to be written in /etc directory. What does
# rpm -qf /etc/sendmail/statistics
# chcon -t etc_aliases_t /etc/sendmail/statistics
should fix it for now.
And last one would need
corecmd_exec_bin() for a source type from AVC msg which we don't have.
Regards, Miroslav
Miroslav Grepl pise:
Ok, hard to say without AVC msgs. But for the first issue
milter_stream_connect_all(sendmail_t)
Then the problem is with
/etc/sendmail/statistics
which is supposed to be written in /etc directory. What does
# rpm -qf /etc/sendmail/statistics
# chcon -t etc_aliases_t /etc/sendmail/statistics
should fix it for now.
Sendmail statistics file now usually resides in /var/log/mail and is with sendmail_log_t label,
-rw-------. root root system_u:object_r:sendmail_log_t:s0 /var/log/mail/statistics
This is in current RHEL and Fedora (it was already in Fedora 13); but I don't know centos.
Zdenek Pytela wrote:
Miroslav Grepl pise:
Ok, hard to say without AVC msgs. But for the first issue
milter_stream_connect_all(sendmail_t)
Then the problem is with
/etc/sendmail/statistics
which is supposed to be written in /etc directory. What does
# rpm -qf /etc/sendmail/statistics
# chcon -t etc_aliases_t /etc/sendmail/statistics
should fix it for now.
Sendmail statistics file now usually resides in /var/log/mail and is with sendmail_log_t label,
-rw-------. root root system_u:object_r:sendmail_log_t:s0 /var/log/mail/statistics
This is in current RHEL and Fedora (it was already in Fedora 13); but I don't know centos.
CentOS is == RHEL - it's rebuilt from source, minus proprietary stuff.
I just looked, and see it there, but it's got a date of 11 Nov 2010, with nothing written there. This machine was newly built, so I'd expect it to work correctly.
mark
selinux@lists.fedoraproject.org