Am 18.01.2019 um 16:17 schrieb Sean smalder73@gmail.com:
I don't have access to a CentOS 6.10 system handy, but it looks like a policy issue. If I take you're ausearch output and pipe it to audit2allow on my CentOS 7.6 system, I get the following:
#============= httpd_t ==============
#!!!! This avc is allowed in the current policy allow httpd_t httpd_sys_script_t:process signull;
Hi Sean, thanks to crosscheck this under EL7.
As showed under EL6 its denied:
# grep signull /var/log/audit/audit.log | audit2allow -m test
module test 1.0;
require { type httpd_t; type httpd_sys_script_t; class process signull; }
#============= httpd_t ============== allow httpd_t httpd_sys_script_t:process signull;
but this brings some insights. It seems therefore to be a allowable policy as it is already allowed under el7. I even found a related changelog entry in the newer EL7 package:
# rpm -qp --changelog selinux-policy-targeted-3.13.1-229.el7.noarch.rpm |egrep 'signul.*apache script' - Allow httpd to send signull to apache script domains and don't audit leaks
So, this let me build and load a custom module with confidence. Thanks!
Noting that on my 7.6 system with selinux enforcing with selinux policy packages at version 3.13.1-229, it notes that your denial would not happen. If you don't have it installed policycoreutils-python provides the audit2allow and audit2why binaries which can help you generate a policy to avoid this denial if you want.
Also, I often find that to truly diagnose the issue, I need to run the following:
# semodule --disable_dontaudit --build # setenforce permissive # tail -f /var/log/audit/audit.log | grep denied | tee ~/denials.out
... then reproduce the problem, and kill the tail. The resulting denials.out file will have a lot of unrelated denials, but if you run audit2allow against the entire file, you'll be able to determine which ones are not relevant by the comments produced (much like above where it told us the "avc is allowed"). You can also use this to generate a custom policy module for your system.
Sometimes there are denials that are not audited which are relevant to the problem, which seems problematic to me...that there is a default set of things that get denied but do not appear in the audit logs. That's a different conversation though.
Anyway, after the data is collected for the denials.out file you can reset to your normal operating stance...
# semodule --build # setenforce enforcing