Bug 1282256 - selinux not logging denial
selinux not logging denial
Status: CLOSED EOL
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted (Show other bugs)
23
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Miroslav Grepl
Ben Levenson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-11-15 15:13 EST by todd_lewis
Modified: 2016-12-20 10:56 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-12-20 10:56:32 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
portion of audit.log after running the "semodule -DB" command. (2.48 KB, text/plain)
2015-11-21 15:11 EST, todd_lewis
no flags Details

  None (edit)
Description todd_lewis 2015-11-15 15:13:43 EST
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.
Comment 1 Miroslav Grepl 2015-11-20 08:35:13 EST
Thank you for this report. Could you please re-test it with

semodule -DB
Comment 2 todd_lewis 2015-11-21 15:11 EST
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.
Comment 3 Fedora End Of Life 2016-11-24 08:27:26 EST
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.
Comment 4 Fedora End Of Life 2016-12-20 10:56:32 EST
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.

Note You need to log in before you can comment on or make changes to this bug.