CentOS - Sep 2017 - 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
pid=19163 comm="/usr/sbin/httpd" name="s.check.cgi"
dev="dm-0"
ino=537182029 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.

Greg

-----Original Message-----From: Clint Dilks <clintd at scms.waikato.ac.nz>
Reply-to: CentOS mailing list <centos at centos.org>
To: CentOS mailing list <centos at centos.org>
Subject: Re: [CentOS] selinux denial of cgi script with httpd using ssl
Date: Tue, 5 Sep 2017 09:38:27 +1200

HI,

Try disabling Don't Audit rules

semodule -DB

Then check /var/log/audit.log

To re-enable

semodule -B






On Tue, Sep 5, 2017 at 5:07 AM, Gregory P. Ennis <PoMec at pomec.net>
wrote:
> Everyone,
>
> 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:
> https://name.domain.com/
>
> 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.
>
> Thanks,
>
> Greg Ennis
>
>
>
> _______________________________________________
> CentOS mailing list
> CentOS at centos.org
> https://lists.centos.org/mailman/listinfo/centos
>
_______________________________________________
CentOS mailing list
CentOS at centos.org
https://lists.centos.org/mailman/listinfo/centos

On Tue, Sep 5, 2017 at 9:49 AM, Gregory P. Ennis <PoMec at pomec.net>
wrote:
> 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
> pid=19163 comm="/usr/sbin/httpd" name="s.check.cgi"
dev="dm-0"
> ino=537182029 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.
>

Hi,

Have you then tried passing this message though audit2why ?

Maybe read through https://wiki.centos.org/HowTos/SELinux if you haven't
already.

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

Am 04.09.2017 um 23:49 schrieb Gregory P. Ennis:
> 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
> pid=19163 comm="/usr/sbin/httpd" name="s.check.cgi"
dev="dm-0"
> ino=537182029 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.
> 
> Greg
 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.

Alexander

On 4 September 2017 at 22:49, Gregory P. Ennis <PoMec at pomec.net> wrote:
> 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
> pid=19163 comm="/usr/sbin/httpd" name="s.check.cgi"
dev="dm-0"
> ino=537182029 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.
>
>
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 :)

On 4 September 2017 at 23:12, Alexander Dalloz <ad+lists at uni-x.org>
wrote:
> Am 04.09.2017 um 23:49 schrieb Gregory P. Ennis:
>
>> 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
>> pid=19163 comm="/usr/sbin/httpd" name="s.check.cgi"
dev="dm-0"
>> ino=537182029 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.
>>
>> Greg
>>
>
> 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.
>
>
>
Don't ever use chcon unless you hate future you or random future team
member when they wonder why things break after a relabelling!

On Tue, Sep 5, 2017 at 9:49 AM, Gregory P. Ennis <PoMec at pomec.net>
wrote:
> 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
> pid=19163 comm="/usr/sbin/httpd" name="s.check.cgi"
dev="dm-0"
> ino=537182029 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.
>

Hi,

Have you then tried passing this message though audit2why ?

Maybe read through https://wiki.centos.org/HowTos/SELinux if you haven't
already.

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

----------------------------------------------------------------------------

Thanks to everyone, I am in the process of working through everyone's
suggestions, will post what I find that works.

Greg