Description of problem: selinux is not generating an audit.log entry when it is denying httpd's exec of an external authentication script. While the denial itself is surprising, as this has worked for years under selinux, it's the lack of an audit.log entry that is the reason for this bug report. Version-Release number of selected component (if applicable): selinux-policy-targeted-3.13.1-154.fc23.noarch libselinux-2.4-4.fc23.i686 How reproducible: Always Steps to Reproduce: 1. configure apache as described below 2. attempt to access protected page (which fails) 3. examine audit.log (no relevant entry) 4. either "setenforce 0" OR "setsebool httpd_unified on" 5. attempt #2 again (which succeeds) Actual results: /var/log/httpd/error_log reports exec of '/var/www/capta/cgi/authnz.pl' failed: (13) Permission denied at step 2 above, but /var/www/capta/cgi/authnz.pl: accepted user='utoddl' pass='********' at step 5 above, while no AVC message was added to audit.log at step 2 above. Expected results: Expected step 2 to work, as it has worked for years; it only stared failing after an upgrade from Fedora 22 to 23. So the fact that selinux was now preventing this was a surprise. However, the more surprising (and relevant for this bug report) result was that no audit.log message is generated for the selinux denial. Additional info: I've been running apache httpd for several years with an external perl script for authentication on a subset of a web site. Upon upgrading to Fedora 23, selinux began preventing httpd's execution of this script. With no audit.log messages to guide me, I set all the httpd_* booleans on, which allowed the script to succeed, then bisected the set of previously "off" booleans back to off until the single "httpd_unified" boolean was the only one left on that would allow httpd to exec the script. During the whole process, not a single audit.log message was generated for any of the denials. Relevant portions of the httpd config are DefineExternalAuth authnz pipe /var/www/capta/cgi/authnz.pl which defines "authnz" external authentication script, and <Directory "/var/www/capta/docs"> AuthType Basic AuthName "Members-only CAPTA content" AuthBasicProvider external AuthExternal authnz require valid-user </Directory> which uses defined authnz script. Again, that this started being denied after an upgrade is merely interesting (and my itself be a bug). The bug I'm reporting here is that no audit.log entries are being generated for the denials.
Thank you for this report. Could you please re-test it with semodule -DB
Created attachment 1097486 [details] portion of audit.log after running the "semodule -DB" command. As the attachment shows, running "semodule -DB" and following the "steps to reproduce" from #1, audit.log messages are produced. However, in working through this, I've found that httpd is allowed to run the external authorization program if it has the same selinux labels as /usr/sbin/httpd -- system_u:object_r:httpd_exec_t:s0 -- rather than system_u:object_r:httpd_sys_content_t:s0 which it has been working with before the upgrade to Fedora 23. In fact the same is true for another external server-side-include script that generates parts of the web site. With these httpd-run external scripts set to the same security context as /usr/sbin/httpd, then the httpd_unified boolean can remain "off". audit2why and audit2allow suggests turning on httpd_unified; however, it seems a cleaner and more precise approach to set the context for the particular httpd-run programs. I'm still surprised it took "semodule -DB" to get these audit.log messages.
This message is a reminder that Fedora 23 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 23. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '23'. 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 23 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 23 changed to end-of-life (EOL) status on 2016-12-20. Fedora 23 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.