Centos – How to fix this dovecot SELinux error in audit.log on CentOS

centoscentos6dovecotselinux

I'm getting these SELinux errors in /var/log/audit/audit.log for dovecot.

type=USER_AUTH msg=audit(1404794536.249:100679): user pid=28375 uid=0 auid=0 ses=2700 subj=unconfined_u:system_r:dovecot_auth_t:s0 msg='op=PAM:authentication acct="starrychloe" exe="/usr/libexec/dovecot/auth" hostname=99.99.99.99 addr=99.99.99.99 terminal=dovecot res=success'
type=USER_ACCT msg=audit(1404794536.260:100680): user pid=28375 uid=0 auid=0 ses=2700 subj=unconfined_u:system_r:dovecot_auth_t:s0 msg='op=PAM:accounting acct="starrychloe" exe="/usr/libexec/dovecot/auth" hostname=99.99.99.99 addr=99.99.99.99 terminal=dovecot res=success'
type=AVC msg=audit(1404794537.473:100681): avc:  denied  { read } for  pid=30020 comm="imap" name="starrychloe" dev=xvde ino=152404 scontext=unconfined_u:system_r:dovecot_t:s0 tcontext=unconfined_u:object_r:home_root_t:s0 tclass=dir
type=SYSCALL msg=audit(1404794537.473:100681): arch=c000003e syscall=2 success=no exit=-13 a0=7fc64f910eb0 a1=0 a2=0 a3=0 items=0 ppid=20321 pid=30020 auid=0 uid=502 gid=501 euid=502 suid=502 fsuid=502 egid=501 sgid=12 fsgid=501 tty=(none) ses=2700 comm="imap" exe="/usr/libexec/dovecot/imap" subj=unconfined_u:system_r:dovecot_t:s0 key=(null)
type=USER_AUTH msg=audit(1404794537.925:100682): user pid=28375 uid=0 auid=0 ses=2700 subj=unconfined_u:system_r:dovecot_auth_t:s0 msg='op=PAM:authentication acct="starrychloe" exe="/usr/libexec/dovecot/auth" hostname=99.99.99.99 addr=99.99.99.99 terminal=dovecot res=success'
type=USER_ACCT msg=audit(1404794537.935:100683): user pid=28375 uid=0 auid=0 ses=2700 subj=unconfined_u:system_r:dovecot_auth_t:s0 msg='op=PAM:accounting acct="starrychloe" exe="/usr/libexec/dovecot/auth" hostname=99.99.99.99 addr=99.99.99.99 terminal=dovecot res=success'
type=USER_AUTH msg=audit(1404794553.944:100684): user pid=28375 uid=0 auid=0 ses=2700 subj=unconfined_u:system_r:dovecot_auth_t:s0 msg='op=PAM:authentication acct="starrychloe" exe="/usr/libexec/dovecot/auth" hostname=99.99.99.99 addr=99.99.99.99 terminal=dovecot res=success'
type=USER_ACCT msg=audit(1404794553.954:100685): user pid=28375 uid=0 auid=0 ses=2700 subj=unconfined_u:system_r:dovecot_auth_t:s0 msg='op=PAM:accounting acct="starrychloe" exe="/usr/libexec/dovecot/auth" hostname=99.99.99.99 addr=99.99.99.99 terminal=dovecot res=success'

I tried

# sealert -a /tmp/dovecot5.log
100% donefound 1 alerts in /tmp/dovecot5.log
--------------------------------------------------------------------------------

SELinux is preventing /usr/libexec/dovecot/imap from read access on the directory starrychloe.

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

If you believe that imap should be allowed read access on the starrychloe 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 imap /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

Then

# cat /tmp/dovecot5.log | audit2allow -M dovecot
******************** IMPORTANT ***********************
To make this policy package active, execute:

semodule -i dovecot.pp

Which generated

# cat dovecot.te

module dovecot 1.0;

require {
        type dovecot_t;
        type home_root_t;
        class dir read;
}

#============= dovecot_t ==============
allow dovecot_t home_root_t:dir read;

However I got this error

# semodule -i dovecot.pp
libsepol.print_missing_requirements: dovecot's global requirements were not met: type/attribute dovecot_t (No such file or directory).
libsemanage.semanage_link_sandbox: Link packages failed (No such file or directory).
semodule:  Failed!

These are the permissions on the directory

# ls -dZ /home/starrychloe
drwxr-xr-x. starrychloe starrychloe unconfined_u:object_r:home_root_t:s0 /home/starrychloe

I'm using CentOS 6.5.

Best Answer

The security context for your home directory is wrong. I'm not sure why setroubleshoot didn't catch that, but the simple fix is to fix the security context.

restorecon /home/starrychloe

Related Solutions

Redhat Apache fast-cgi selinux permissions

Running FastCGI your way leaves a big security hole: the PHP interpreter is run as user "httpd" (at least I can't see anything about suexec here).

We have a working setup with SELinux and PHP as FastCGI here at CentOS 6, but it was really tricky to get everything working.

A few tips for the start:

you don't need to reboot to disable/enable selinux - just use the command "setenforce 0" or "setenforce 1" :)
always try to get everything working with SELinux disabled, then enable it and have a look at audit.log

Here we go:

enable suexec
change SELinux type for php.fcgi to httpd_fastcgi_script_exec_t
your FastCGI starter (php.fcgi) should not be writable by the user owning it (otherwise he can tweak many settings and limits). Give it the "immutable" flag: chattr +i php.fcgi

suexec has some trouble with FastCGI, so we have to make it permissive:

yum install policycoreutils-python
semanage permissive -a httpd_suexec_t

Good luck!

Centos – Configure selinux to allow openldap on CentOS 6.4

If you filter the audit logs through audit2allow(1) and audit2why you'll get an approximate idea of what is happening:

#============= slapd_t ==============
allow slapd_t self:capability sys_nice;
allow slapd_t var_log_t:file { write read };
------------------------------------

    Was caused by:
            Missing type enforcement (TE) allow rule.

            You can use audit2allow to generate a loadable module to allow this access.

type=AVC msg=audit(1372888328.408:3263): avc:  denied  { sys_nice } for  pid=1492 comm=slapd capability=23  scontext=unconfined_u:system_r:slapd_t:s0 tcontext=unconfined_u:system_r:slapd_t:s0 tclass=capability

    Was caused by:
            Missing type enforcement (TE) allow rule.

            You can use audit2allow to generate a loadable module to allow this access.

type=AVC msg=audit(1372888328.424:3264): avc:  denied  { read } for  pid=1493 comm=slapd name=log.0000000001 dev=dm-0 ino=263969 scontext=unconfined_u:system_r:slapd_t:s0 tcontext=unconfined_u:object_r:var_log_t:s0 tclass=file

    Was caused by:
            Missing type enforcement (TE) allow rule.

            You can use audit2allow to generate a loadable module to allow this access.

Checking labeling

It is unlikely a label restore prevents you from starting a service if SELinux is in permissive mode. Also, why the -F switch?

To know if you have to restore the labeling of a directory or file, first find out what context a file or directory is supposed to have:

# matchpathcon /etc/openldap/
/etc/openldap   system_u:object_r:etc_t:s0

Then list its security context:

# ls -ldZ /etc/openldap/
drwxr-xr-x. root root system_u:object_r:etc_t:s0       /etc/openldap//

In this example, no further action is needed.

With regards to your issue, the problem is not labeling per se, but a missing type enforcement rule, i.e., a rule that allows a labeled process to transition from one confined domain to another, or to read files with an specific label, for example.

Creating an SELinux module

You can try to build a module that allows the slapd_t to perform the operations which appeared in the audit.log. It is probable that you need further adjustments in your code. Use audit2allow, and make for this task. All commands are very well documented in their respective manpages. The process will look roughly like this (after copying the relevant messages into audit.txt):

audit2allow -i audit.txt -m slapd -o slapd.te
make -f /usr/share/selinux/devel/Makefile load

Also, check if a bug report for the SELinux policy regarding this issue already exists.