Bug 981878 - SELinux is preventing smtpd from read, write access on the file /var/spool/postfix/pid/inet.submission.
SELinux is preventing smtpd from read, write access on the file /var/spool/po...
Status: CLOSED EOL
Product: Fedora
Classification: Fedora
Component: dovecot (Show other bugs)
19
x86_64 Unspecified
unspecified Severity high
: ---
: ---
Assigned To: Michal Hlavinka
Fedora Extras Quality Assurance
abrt_hash:41d0a577626b2c31ad356315f11...
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-07-06 11:27 EDT by Trever Adams
Modified: 2015-02-17 10:54 EST (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 964679
Environment:
Last Closed: 2015-02-17 10:54:31 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Trever Adams 2013-07-06 11:27:25 EDT
+++ This bug was initially created as a clone of Bug #964679 +++

Description of problem:
SELinux is preventing smtpd from read, write access on the file /var/spool/postfix/pid/inet.submission.

selinux-policy-3.12.1-57.fc19.noarch
selinux-policy-targeted-3.12.1-57.fc19.noarch

postfix/master[1035]: warning: process /usr/libexec/postfix/cleanup pid 1122 exit status 1
postfix/smtpd[1128]: fatal: open lock file pid/inet.smtp: cannot open file: Permission denied
postfix/master[1035]: warning: process /usr/libexec/postfix/smtpd pid 1128 exit status 1
postfix/cleanup[1134]: fatal: open lock file pid/unix.cleanup: cannot open file: Permission denied
postfix/master[1035]: warning: process /usr/libexec/postfix/cleanup pid 1134 exit status 1
postfix/smtpd[1138]: fatal: open lock file pid/inet.smtp: cannot open file: Permission denied
postfix/master[1035]: warning: process /usr/libexec/postfix/smtpd pid 1138 exit status 1

setenforce 0 fixes the problem.

selinux seems to be VERY broken, as I have it in permissive mode and so setenforce 0 should NOT cause different behavior!
Comment 1 Trever Adams 2013-07-07 14:09:30 EDT
This was not fixed in -59.
Comment 2 Daniel Walsh 2013-07-08 15:03:58 EDT
Could you attahc the AVCs you are seeing?

Does 

restorecon -R -v /var/spool/postfix 

change any labels?
Comment 3 Trever Adams 2013-07-08 17:54:23 EDT
No, none.

This bug also does:
* keep zabbix agent from starting
* can keep httpd (apache) and mysqld (maridb, I guess) from starting
* keeps bind from starting, at least if it is using dlz module from samba 4 in /usr/local/samba
* others which I am not bothering with at the moment

I know I relabeled the samba stuff a long time ago.

As said, this is in permissive mode, why is it blocking anything?!?
Comment 4 Trever Adams 2013-07-08 17:57:48 EDT
This also keeps opendkim from starting.
Comment 5 Trever Adams 2013-07-08 18:31:31 EDT
avc:  denied  { lock } for  pid=14340 comm="smtpd" path="/var/spool/postfix/pid/inet.smtp" dev="dm-0" ino=1315283 scontext=system_u:system_r:postfix_smtpd_t:s0 tcontext=system_u:object_r:postfix_var_run_t:s0 tclass=file

avc:  denied  { name_bind } for  pid=1095 comm="opendkim" src=13626 scontext=system_u:system_r:dkim_milter_t:s0 tcontext=system_u:object_r:unreserved_port_t:s0 tclass=udp_socket

avc:  denied  { getattr } for  pid=14348 comm="cleanup" path="/var/spool/postfix/pid/unix.cleanup" dev="dm-0" ino=1315097 scontext=system_u:system_r:postfix_cleanup_t:s0 tcontext=system_u:object_r:postfix_var_run_t:s0 tclass=file

avc:  denied  { getattr } for  pid=14346 comm="smtpd" path="/var/spool/postfix/pid/inet.localhost:10025" dev="dm-0" ino=1315284 scontext=system_u:system_r:postfix_smtpd_t:s0 tcontext=unconfined_u:object_r:postfix_var_run_t:s0 tclass=file

avc:  denied  { open } for  pid=14303 comm="smtpd" path="/var/spool/postfix/pid/inet.localhost:10025" dev="dm-0" ino=1315284 scontext=system_u:system_r:postfix_smtpd_t:s0 tcontext=unconfined_u:object_r:postfix_var_run_t:s0 tclass=file

avc:  denied  { read write } for  pid=14297 comm="smtpd" name="inet.smtp" dev="dm-0" ino=1315283 scontext=system_u:system_r:postfix_smtpd_t:s0 tcontext=system_u:object_r:postfix_var_run_t:s0 tclass=file

avc:  denied  { open } for  pid=14249 comm="smtpd" path="/var/spool/postfix/pid/inet.localhost:10025" dev="dm-0" ino=1315284 scontext=system_u:system_r:postfix_smtpd_t:s0 tcontext=unconfined_u:object_r:postfix_var_run_t:s0 tclass=file

avc:  denied  { setpgid } for  pid=738 comm="zabbix_agentd" scontext=system_u:system_r:zabbix_agent_t:s0 tcontext=system_u:system_r:zabbix_agent_t:s0 tclass=process

avc:  denied  { write } for  pid=13792 comm="auth" name="krb5.cc" dev="dm-0" ino=524311 scontext=system_u:system_r:dovecot_auth_t:s0 tcontext=unconfined_u:object_r:dovecot_etc_t:s0 tclass=file

avc:  denied  { create } for  pid=6771 comm="dovecot" name="auth-client" scontext=system_u:system_r:dovecot_t:s0 tcontext=system_u:object_r:var_run_t:s0 tclass=sock_file


There may be others, but it is being hard to weed out with so many.
Comment 6 Samuel Sieb 2013-07-08 20:39:17 EDT
You say you are in permissive mode, but it doesn't appear to be that way as setenforce changes the behaviour.  What did you do that you think it is in permissive mode?
Comment 7 Trever Adams 2013-07-08 20:43:00 EDT
Because in /etc/selinux/config it says:

SELINUX=permissive
SELINUXTYPE=targeted
Comment 8 Samuel Sieb 2013-07-08 20:47:55 EDT
It appears that's not taking effect for some reason.  You can run getenforce to check the current state.
Comment 9 Trever Adams 2013-07-08 20:53:11 EDT
You are correct, getenforce on reboot says it is in Enforcing mode.
Comment 10 Daniel Walsh 2013-07-09 17:19:03 EDT
Trever that is strange that this would fail to put the machine into permissive mode.

What port is 13626?  Is this a standard port that opendkim uses?
Comment 11 Daniel Walsh 2013-07-09 17:21:38 EDT
avc:  denied  { write } for  pid=13792 comm="auth" name="krb5.cc" dev="dm-0" ino=524311 scontext=system_u:system_r:dovecot_auth_t:s0 tcontext=unconfined_u:object_r:dovecot_etc_t:s0 tclass=file

This is one we have no seen before Does auth write the kerberos credential file to /etc/dovecot  by default?
Comment 12 Trever Adams 2013-07-09 18:28:11 EDT
opendkim on my system is almost completely stock. I do NOT modify ports in any way. Based on my documentation as I was setting things up, the port it talks to postfix on is 8891. I do not know what port 13626 is or why it is being used.

I do not know why the permissive doesn't work. I believe it started after:
Jul 05 15:46:44 Updated: selinux-policy-3.12.1-57.fc19.noarch
Jul 05 15:47:01 Updated: selinux-policy-targeted-3.12.1-57.fc19.noarch

It may have been a bit earlier.

I do not know why it is trying to write to krb5.cc. This file is necessary for GSSAPI auth for LDAP look-ups. kinit is done by a cronjob which runs as root and then chowns the file to the appropriate users. (Dovecot does handle tickets for Kerberos auth to its own services.) This is a setup a few people use (it was kind of developed by myself and a few others on the dovecot mailing list to get LDAP working more securely). If this doesn't follow FHS or if there are selinux labeling I need to do, I would love pointers on how to fix that.

I would love to know the auth-client fix as well as I have an auth-client for Prosody that will likely be denied as well.
Comment 13 Trever Adams 2013-07-10 05:54:02 EDT
Ummm, no, I do not believe this isn't a dovecot bug. This is selinux because:

a) permissive mode is broken with the recent updates
b) this affects several packages (dovecot, postfix, zabbix, etc.)
Comment 14 Daniel Walsh 2013-07-10 19:48:49 EDT
Can you attach the /etc/selinux/config

If permissive mode was broken, I think we would be hearing it from lots of people, this is the only bug report that we have heard it.

We have lots of fixes that have been added to the latest policy selinux-policy-3.12.1-62.

We have not allowed 

allow dovecot_auth_t dovecot_etc_t:file write;

Is not allowed yet, since we are waiting to here what the dovecot maintainer wants to do,  personally I would prefer if the CC files were written under /run.

allow zabbix_agent_t self:process setpgid;

Did not make it into the latest policy but will be in the next one.

# sepolicy network -d dkim_milter_t
dkim_milter_t: tcp name_connect
	53
	88, 750, 4444
	9080
dkim_milter_t: tcp name_bind
	8891

We currently allow these ports for dkim_milter_t
Comment 15 Trever Adams 2013-07-10 20:04:20 EDT
These problems affect at least 4 systems I have. (Not all use the mail components but have zabbix, and other problems.)

The config:

# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
#     enforcing - SELinux security policy is enforced.
#     permissive - SELinux prints warnings instead of enforcing.
#     disabled - No SELinux policy is loaded.
SELINUX=permissive
# SELINUXTYPE= can take one of these two values:
#     targeted - Targeted processes are protected,
#     mls - Multi Level Security protection.
SELINUXTYPE=targeted 


I see nothing in /var/log/messages about /etc/selinx/config not being readable or invalid.

If it is more proper for me to place it in /run/dovecot, I am quite happy to do so. It would take me about 10 minutes to clean up my documentation and change the few systems over. Again, I am not sure why it rights to this file unless something in kerberos code writes when it auths.

You haven't touched on the /var/spool/postfix/pid/* problems either, at least not that I am seeing.

/var/spool/postfix/pid/unix.cleanup, inet.localhost*, inet.smtp, unix.lmtp

These are open, getattr, lock, read/write.
Comment 16 Trever Adams 2013-07-10 20:14:56 EDT
The follow is from boot with:

selinux-policy-targeted-3.12.1-63.fc19.noarch
libselinux-utils-2.1.13-15.fc19.x86_64
libselinux-devel-2.1.13-15.fc19.x86_64
libselinux-2.1.13-15.fc19.x86_64
selinux-policy-3.12.1-63.fc19.noarch


[   28.250971] type=1400 audit(1373501310.249:4): avc:  denied  { dac_override } for  pid=716 comm="opendkim" capability=1  scontext=system_u:system_r:dkim_milter_t:s0 tcontext=system_u:system_r:dkim_milter_t:s0 tclass=capability
[   28.250995] type=1400 audit(1373501310.249:5): avc:  denied  { dac_read_search } for  pid=716 comm="opendkim" capability=2  scontext=system_u:system_r:dkim_milter_t:s0 tcontext=system_u:system_r:dkim_milter_t:s0 tclass=capability
[   29.033022] type=1400 audit(1373501311.031:6): avc:  denied  { setpgid } for  pid=747 comm="zabbix_agentd" scontext=system_u:system_r:zabbix_agent_t:s0 tcontext=system_u:system_r:zabbix_agent_t:s0 tclass=process
[   31.392230] type=1400 audit(1373501313.597:7): avc:  denied  { create } for  pid=705 comm="dovecot" name="auth-client" scontext=system_u:system_r:dovecot_t:s0 tcontext=system_u:object_r:var_run_t:s0 tclass=sock_file
[   52.562543] type=1400 audit(1373501334.768:8): avc:  denied  { read } for  pid=842 comm="postconf" name="unix" dev="proc" ino=4026532002 scontext=system_u:system_r:antivirus_t:s0 tcontext=system_u:object_r:proc_net_t:s0 tclass=file
[   52.578989] type=1400 audit(1373501334.784:9): avc:  denied  { write } for  pid=845 comm="amavisd-snmp-su" name="/" dev="tmpfs" ino=7937 scontext=system_u:system_r:antivirus_t:s0 tcontext=system_u:object_r:var_run_t:s0 tclass=dir
[   71.313990] type=1400 audit(1373501353.519:10): avc:  denied  { read } for  pid=933 comm="polkitd" name="machine" dev="cgroup" ino=8165 scontext=system_u:system_r:policykit_t:s0 tcontext=system_u:object_r:cgroup_t:s0 tclass=dir
[  121.675376] type=1400 audit(1373501403.881:11): avc:  denied  { read write } for  pid=991 comm="smtpd" name="inet.smtp" dev="dm-0" ino=1315283 scontext=system_u:system_r:postfix_smtpd_t:s0 tcontext=system_u:object_r:postfix_var_run_t:s0 tclass=file



NOTE: I just checked the grub2.cfg file to see if enforcing was set there. It is not.
Comment 17 Trever Adams 2013-07-10 20:17:30 EDT
Is this the problem?

# fixfiles relabel

    Files in the /tmp directory may be labeled incorrectly, this command
    can remove all files in /tmp.  If you choose to remove files from /tmp,
    a reboot will be required after completion.

    Do you wish to clean out the /tmp directory [N]?  N
Relabeling / /boot /dev /dev/hugepages /dev/mqueue /dev/pts /dev/shm /home /run /sys /sys/fs/cgroup /system-upgrade-root /tmp /usr/lib64/plymouth /usr/lib/modules/3.9.1-301.fc19.x86_64
34.0%/etc/selinux/targeted/contexts/files/file_contexts: has invalid context system_u:object_r:amanda_unit_file_t:s0
63.4%
Comment 18 Miroslav Grepl 2013-07-12 08:30:05 EDT
Well we see more bugs together in this one bug. Could you open a new one with AVC msgs in

https://bugzilla.redhat.com/show_bug.cgi?id=981878#add_comment

and keep this bug for


allow dovecot_auth_t dovecot_etc_t:file write;
Comment 19 Trever Adams 2013-07-12 09:38:42 EDT
Sure. Thank you for letting me know.

I have moved my krb5.cc to /run/doveceot. I am sorry, I remembered why the krb5.cc was being written to. I was letting ldap get the service ticket and only got the tgt myself. This is why it was trying to write to the krb5.cc.

Having moved it, I am not seeing any AVC messages relating to that file itself.
Comment 20 Trever Adams 2013-07-26 11:26:26 EDT
There is one problem with /run/dovecot, it is a tmpfs and to save load on the kerberos system, this is managed from crontab and the actual ticket is only fetched every other day via crontab.
Comment 21 Fedora End Of Life 2015-01-09 13:42:57 EST
This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 19 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 22 Fedora End Of Life 2015-02-17 10:54:31 EST
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.