SElinux context for Xojo shared libraries in cgi-bin

Hi all,

I’ve searched the forum and found a few fragments that relate to this, but nothing that seems to get me to a solution at this point.

I have a simple Linux console application that currently just prints hello and exits. If I put the compiled app into my apache cgi-bin directory and call it from a web form, I get a page returned that says hello.

However this only works with SELinux temporarily disabled on our CentOS 7 server. With SELinux enabled (which is required on the server) I get a type 500 error and the message below that the shared library couldn’t be loaded:

AH01215: /var/www/cgi-bin/mycgi: error while loading shared libraries: cannot open shared object file: No such file or directory

By default the library folder inherited the context of the cgi-bin folder so:

-rwxr-xr-x. apache apache unconfined_u:object_r:httpd_sys_script_exec_t:s0 mycgi
But I’m guessing the shared libraries should maybe be something like shlib_t. So I tried:

chcon -v --type=shlib_t

which results in

-rwxr-xr-x. apache apache unconfined_u:object_r:lib_t:s0

But am still getting the same type 500 with SELinux enabled. Could anyone point out the correct SELinux security context for
Xojo shared libraries when executing as apache scripts?

Thanks for any tips or links.


Have you looked at /var/log/audit/ to see what the specific errors are?

Hi Greg. I did, but there’s nothing very much in there that I can see that relates the shared library file (I should note the actual name of my app is doWebINSIGHT):

# cat /var/log/audit/audit.log | grep httpd type=AVC msg=audit(1542213527.526:998576): avc: denied { execstack } for pid=124583 comm="doWebINSIGHT" scontext=system_u:system_r:httpd_sys_script_t:s0 tcontext=system_u:system_r:httpd_sys_script_t:s0 tclass=process type=AVC msg=audit(1542213527.526:998576): avc: denied { execmem } for pid=124583 comm="doWebINSIGHT" scontext=system_u:system_r:httpd_sys_script_t:s0 tcontext=system_u:system_r:httpd_sys_script_t:s0 tclass=process type=SYSCALL msg=audit(1542213527.526:998576): arch=c000003e syscall=10 success=yes exit=0 a0=7fff10cd9000 a1=1000 a2=1000007 a3=0 items=0 ppid=12455 pid=124583 auid=4294967295 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) ses=4294967295 comm="doWebINSIGHT" exe="/var/www/cgi-bin/doWebINSIGHT" subj=system_u:system_r:httpd_sys_script_t:s0 key=(null)

Oh it absolutely does. httpd is not allowed the load/execute the library.

FWIW, If you don’t want to deal with this on your own, we use SELinux on all Xojo Cloud servers.

Thanks again Greg. Unfortunately the cloud option isn’t really available to us. This is eventually going to be working on very large amounts of genomic data that we’re encouraged not to host off-site.

I did try “setsebool -P httpd_execmem 1” which made the errors disappear from the SELinux log. But it didn’t change the type 500 errors nor the errors in the apache log and I’m kind of thinking I’ll flip that back to 0 shortly if this isn’t part of a fix.

Would you be able to share how this has been enabled in the Xojo cloud environment? It seems kind of a terminal app 101 that we should be able to get cgi’s running under SELinux.

We built several proprietary tools for dealing with SELinux so I cannot give you that info.

That said, this should give you a direction to go:

Perfect that totally sorted it out, thanks a lot for the link!

It turned out that

setsebool -P httpd_execmem 1

was indeed the correct solution for the visible part of the problem. However there were additional silent denials going on that weren’t showing up in the SELinux audit log. Hence the apache log errors with no audit log errors. So:

service auditd rotate semodule -DB audit2allow -a -M mycertwatch semodule -i mycertwatch.pp

Fixed things. It turned out that the silent denials related to:

allow httpd_t httpd_sys_script_t:process { noatsecure rlimitinh siginh };

I guess I should now investigate the security implications of allowing these and whether we may want to run this on a less critical server. But for now, the cgi works which is great. Thanks again for your help with this!