Selinux Denial Of Cgi Script With Httpd Using Ssl

Home » CentOS » Selinux Denial Of Cgi Script With Httpd Using Ssl
CentOS 7 Comments


I am trying to use a cgi perl script for a CentOS 7 website that works fine with selinux in permissive mode but fails with selinux in enforcing mode.

The problem I have is that I can not find where the selinux error message is being recorded.

It does not appear to be in the /var/log/messages or /var/log/audit/audit.log. I do not get any /var/log/httpd/ssl_error_log entries. I do get a successful entry into /var/log/httpd/ssl_access_log and ssl_request_log when selinux is in permissive mode, but not when selinux is in enforcing mode.

The only place I can see that I am getting an error message is in the
/var/log/httpd/error_log which is as follows :

Mon Sep 04 11:40:24.216569 2017] [cgi:error] [pid 2290] [client x.x.x.x:55748] AH01215: (13)Permission denied: exec of
‘/var/www/cgi-bin/name.of.script.cgi’ failed, referer:

When selinux is in permissive mode the above error does not occur and the script works fine. When selinux is in enforcing mode the above error occurs, and the cgi script fails to execute.

Is there a way to increase the sensitivity of selinux loging, or is there a different place to look for the error that prevents the execution of the script.

Your help would be appreciated.


Greg Ennis

7 thoughts on - Selinux Denial Of Cgi Script With Httpd Using Ssl

  • Thanks for your help.

    I did pick up an additional entry in the audit file :

    type=AVC msg=audit(1504561395.709:10196): avc: denied { execute } for pid163 comm=”/usr/sbin/httpd” name=”s.check.cgi” dev=”dm-0″
    inoS7182029 scontext=system_u:system_r:httpd_t:s0
    tcontext=unconfined_u:object_r:httpd_sys_content_t:s0 tclass=file

    Unfortunately, I am not sure how the above tells me what is wrong.


    —–Original Message—–From: Clint Dilks
    Reply-to: CentOS mailing list
    To: CentOS mailing list

    Subject: Re: [CentOS] selinux denial of cgi script with httpd using ssl Date: Tue, 5 Sep 2017 09:38:27 +1200


    Try disabling Don’t Audit rules

    semodule -DB

    Then check /var/log/audit.log

    To re-enable

    semodule -B

  • Am 04.09.2017 um 23:49 schrieb Gregory P. Ennis:

    From above log entry you see that the file object denied to execute
    (‘/var/www/cgi-bin/name.of.script.cgi) has the SELinux context type httpd_sys_content_t.

    # semanage fcontext -l | grep ‘/var/www/cgi-bin’
    /var/www/cgi-bin(/.*)? all files system_u:object_r:httpd_sys_script_exec_t:s0
    [ … ]

    The permitted type is httpd_sys_script_exec_t.

    `restorecon -Rv /var/www/cgi-bin/’ can fix it. Or more targeted `chcon
    -t httpd_sys_script_exec_t /var/www/cgi-bin/name.of.script.cgi’.

    Both audit2why and audit2allow suggest to activate a boolean which you may not want to set as it disables a more fine grained priviledge separation in the context of httpd actions.


  • Odd it was in the don’t audit logs, as I think that should be logged normally.

    Executable scripts should be httpd_sys_script_exec_t rather than httpd_sys_content_t, as the latter is just read only content files rather than something to be executed.

    The default policy has the cgi-bin directory contents labelled correctly by default though …

    Could you please post the output of ‘semanage fcontext -lC’ … this will list any local file context modifications.

    You could try restorecon -Rv /var/www to see if that fixes your labelling, if you’ve not made any local modifications.

    If you have made local modifications to set the contents of cgi-bin to httpd_sys_content_t then you should remove those with semanage fcontext -d
    ‘/var/www/cgi-bin’ or whatever the pattern for the local modification is as that’s incorrect labelling.

    While you’re checking selinux configuration do a quick getsebool httpd_enable_cgi … it’s on by default but worth verifying :)

  • Don’t ever use chcon unless you hate future you or random future team member when they wonder why things break after a relabelling!

  • Hi,

    Have you then tried passing this message though audit2why ?

    Maybe read through if you haven’t already.

    If you want something simpler maybe try installing setroubleshoot and setroubleshoot-server.