SELinux is permissive mode to help avoid operational issues during a transition to a new RHEL7 server deployment. Whilst some SELinux issues are fairly easy to review and resolve with a modicum of confidence, I find the following somewhat perplexing.

The AVC is as follows:

type=AVC msg=audit(1533595368.668:140747): avc: denied { connectto } for pid=87400 comm="postdrop" path="/var/spool/postfix/public/pickup" scontext=system_u:system_r:postfix_postdrop_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=unix_stream_socket 

audit2why says:

type=AVC msg=audit(1533595368.668:140747): avc: denied { connectto } for pid=87400 comm="postdrop" path="/var/spool/postfix/public/pickup" scontext=system_u:system_r:postfix_postdrop_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=unix_stream_socket Was caused by: Missing type enforcement (TE) allow rule. You can use audit2allow to generate a loadable module to allow this access. 

audit2allow says:

#============= postfix_postdrop_t ============== #!!!! The file '/var/spool/postfix/public/pickup' is mislabeled on your system. #!!!! Fix with $ restorecon -R -v /var/spool/postfix/public/pickup allow postfix_postdrop_t unconfined_t:unix_stream_socket connectto; 

The notice seems to imply that some part of the problem should be corrected by running something like:

# restorecon -R -v /var/spool/postfix/public/pickup # ls -lZ /var/spool/postfix/public/pickup srw-rw-rw-. postfix postfix unconfined_u:object_r:postfix_public_t:s0 /var/spool/postfix/public/pickup 

The SELinux audit logged issues, however, do not seem to change after that is done, so, apparently there is more to be done. Presumably some of the issue is related to the audit2allow mention of:

allow postfix_postdrop_t unconfined_t:unix_stream_socket connectto; 

It seems odd that a SELinux issue with a very well established service like postfix should require administrator intervention.

Likely a path to resolving the issue might be along the lines of:

# echo 'type=AVC msg=audit(1533595368.668:140747): avc: denied { connectto } for pid=87400 comm="postdrop" path="/var/spool/postfix/public/pickup" scontext=system_u:system_r:postfix_postdrop_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=unix_stream_socket' \ | audit2allow -M local_postfix_pickup # semodule -i local_postfix_pickup.pp 

That said, it seems unwise to simply do things to disappear the audit issues without a better understanding of why such a change should be considered legitimate.

Is this really a labeling issue, or is it only a side-effect of the missing "allow", and, can anyone comment about whether this is a legitimate, expected change that an administrator should have to make to get a postfix installation running smoothly under SELinux?

Please do not suggest to turn off SELinux. Certainly that is an option, but I'd rather learn how to leave it on and to learn how to discern the proper course of action to do so when issues of this nature arise.A

NOTE: The aforementioned audit2allow -M .. and semanage -i commands do resolve SELinux issues without relabeling, but it remains unclear if a relabel might have averted a need to create the policy. It remains unclear whether resolving the problem in this way is expected and/or normal.

#============= postfix_postdrop_t ============== #!!!! This avc is allowed in the current policy allow postfix_postdrop_t unconfined_t:unix_stream_socket connectto;