Bug 981878

This was not fixed in -59.

Could you attahc the AVCs you are seeing?

Does 

restorecon -R -v /var/spool/postfix 

change any labels?

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?!?

This also keeps opendkim from starting.

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.

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?

Because in /etc/selinux/config it says:

SELINUX=permissive
SELINUXTYPE=targeted

It appears that's not taking effect for some reason.  You can run getenforce to check the current state.

You are correct, getenforce on reboot says it is in Enforcing mode.

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?

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?

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.

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.)

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

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.

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.

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%

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;

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.

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.

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.

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.