Skip to main content
Unix & Linux

Return to Question

Another change to the title to try to make it more productive to others who face the issue even if details are different.
Link
kbulgrien
kbulgrien
  • 890
  • 7
  • 23

Are both mitigations required when audit2allow suggests both restorecon and one type enforcement rule change?

Make the question title more generic as the principle applies to more than postfix. Reformat a long command to avoid hiding audit2allow.
Source Link
kbulgrien
kbulgrien
  • 890
  • 7
  • 23

The file '/var/spool/postfix/public/pickup' is mislabeled on your system Are both mitigations required when audit2allow suggests both restorecon and one rule change?

# 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

The file '/var/spool/postfix/public/pickup' is mislabeled on your system

# 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

Are both mitigations required when audit2allow suggests both restorecon and one rule change?

# 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
Add note to show the proposes audit2allow/semanage commands to appear to alleviate the audit issue.
Source Link
kbulgrien
kbulgrien
  • 890
  • 7
  • 23

Is this really a labeling issue, or is it simplyonly 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;

Is this a labeling issue, or is it simply 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.

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;
Source Link
kbulgrien
kbulgrien
  • 890
  • 7
  • 23