mjhjmtu

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;

In fact, since restorecon was used, these commands are not required to resolve SELinux issues:

# 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

Here's why, and hopefully and explanation that can help when one is attempting to resolve SELinux audit issues.

• 
  

  Take care to notice the types before mitigation steps. In this case:

  
  
  

  unix_stream_socket

  
  
  

  It is unfortunate that ls -lZ /var/spool/postfix/public/pickup was not run before the restorecon command was run, as this would have helped with gaining understanding.

  
  
  

  TIP: Look at the SELinux contexts before making changes.

  
  


• 
  

  Notice the SELinux type after restorecon -R -v /var/spool/postfix/public/pickup was run:

  
  
  

  postfix_public_t

  
  
  

  It is important to note that a type change did occur.

  
  
  

  TIP: When both a suggested restorecon command and a single allow rule is listed, it is not unlikely that the mitigation suggestions are alternative solutions (either, not both, may resolve the issue).

  
  


• 
  

  Notice that the audit2allow output changed such that the suggested restorecon command is no longer present.

  
  
  

  When audit2allow output has both a restorecon command and only one rule change, after a mitigation attempt using restorecon, very likely the problem is solved. The key here is realizing that the rule displayed for the AVC is no longer relevant, because there is no longer any reason for a rule regarding a type that is no longer in use.

  
  
  

  For example, in this specific case, there is no reason for postfix_postdrop_t to be given access to a unix_stream_socket when that socket now has a top of postfix_public_t.

  
  

In any other case like this, it is important to remember that the AVC itself is for a historic event. Since the AVC is for a historical event, one should bear in mind that alternative solutions to old problems may not be required if the details in the alternative solution are no longer identical to the state of the system at the time the event occurred. In other words, once the restorecon command was used, it is not necessary to expect "allowed in the current policy" messages when a restorecon suggestion is no longer present.

In case you are still wondering about the wisdom of not using both mitigations, take comfort in the fact that, if both mitigations were actually required, a future audit event will occur.

There is actually a side benefit to NOT using multiple mitigations. Remember, the whole point of SELinux is to constrain processes to accessing things that they actually need. If unnecessary type enforcement changes are made, then the postfix_postdrop_t executable is no longer constrained from accessing other unix_stream_socket resources that have nothing to do with running postfix, and a legitimate run-time constraint on postfix would be subverted.

A more appropriate title for this question might be: "Are both mitigations required when audit2allow suggests both restorecon and one rule change?"