SELinux notes

From DISI
Revision as of 18:08, 1 July 2019 by Benrwong (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

SELinux is the bane of many administrators and yours truly is no exception.

When an SELinux denial occurs, it may not be obvious. You may get a permission error but have perfectly fine Linux permissions. The issue may reside in SELinux permissions which are called SELinux contexts. To view an SELinux context, do an ls with the -Z flag.

Here is the SELinux context of an executable:

[root@n-1-141 ~]# ls -lhZ /bin/dbus-daemon 
-rwxr-xr-x. root root system_u:object_r:dbusd_exec_t:s0 /bin/dbus-daemon

Typically, SELinux context is divided into four parts: user, type, role, and level

The above SELinux context above is:

SELinux user: system_u
SELinux role: object_r
SELinux type: dbusd_exec_t
SELinux level: s0

Example: SELinux Denials in Schrodinger

Around Spring of 2019, I had a huge amount of issues with Schrodinger GPU jobs failing for apparently little reason. The failures occurred on the compute nodes such as n-1-126, n-1-141 and n-9-34,36. The error messages kept complaining about "arguments to dbus_move_error()". Eventually, for the heck of it, we tried turning off SELinux and then the software worked. But, we don't want to just turn SELinux off just since it does work well as a security measure. This is how we worked around it in SELinux:

1) Investigate /var/log/audit/audit.log. This is the log file for any SELinux allowance or denial.
2) The audit.log file can be notoriously difficult to read because of the dense amount of information. Also try installing tools like setools and setroubleshoot.
3) Find relevant denial messages with sealert -a /var/log/audit/audit.log or grep for denial messages
My denial messages looked like this:

[root@n-1-141 ~]# grep denied /var/log/audit/audit.log
type=USER_AVC msg=audit(1562000684.669:92823): user pid=4595 uid=81 auid=4294967295 ses=4294967295 subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 msg='avc:  denied  { send_msg } for msgtype=method_return dest=:1.314 spid=4888 tpid=11427 scontext=system_u:system_r:hald_t:s0 tcontext=system_u:system_r:sge_job_t:s0 tclass=dbus  exe="/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?'
type=USER_AVC msg=audit(1562000897.290:92831): user pid=4595 uid=81 auid=4294967295 ses=4294967295 subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 msg='avc:  denied  { send_msg } for msgtype=method_return dest=:1.315 spid=4888 tpid=13754 scontext=system_u:system_r:hald_t:s0 tcontext=system_u:system_r:sge_job_t:s0 tclass=dbus  exe="/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?

Take note of the following:
scontext is the SELinux context of the source process which initiated a request
tcontext is the SELinux context of the target process that the source process is attempting to access

You can see that scontext and tcontext differ in the SELinux type which may sometimes cause issues.

4) Use audit2allow to view what you need to do to resolve the SELinux conflicts. audit2allow reads the conflict messages in audit.log and then outputs what you need to do to resolve the issue.

[root@n-1-141 audit]# audit2allow -a 
#============= hald_t ==============
allow hald_t sge_job_t:dbus send_msg;

5) Use audit2allow with -M flag to generate a new semanage module that will edit SELinux policy and resolve conflict. The name following the -M can be customized

[root@n-1-141 ~]# audit2allow -a -M sgehald
******************** IMPORTANT ***********************
To make this policy package active, execute:
semodule -i sgehald.pp
The previous command will generate two files, a binary and a type enforcement file
[root@n-1-141 ~]# ls -lh sgehald*
-rw-r--r--. 1 root root 911 Jul  1 10:59 sgehald.pp
-rw-r--r--. 1 root root 163 Jul  1 10:59 sgehald.te

6) Install the policy package with semodule:

[root@n-1-141 ~]# semodule -i sgehald.pp 

teague notes

Usually if there is a problem with an selinux context, it’s usually the type. For http you want the types to match what’s in the /etc/httpd/ directory. There are generally three types for http: content, logs and conf. Here is how I got the wiki to work:

chcon -t httpd_config_t /domains/wiki.ucsf.bkslab.org/wiki.ucsf.bkslab.org.conf
chcon -R -t httpd_log_t /domains/wiki.ucsf.bkslab.org/logs
chcon -R -t httpd_user_content_t /domains/wiki.ucsf.bkslab.org/htdocs
chcon -R -t httpd_sys_script_rw_t /domains/wiki.ucsf.bkslab.org/htdocs/images
chcon -R -t httpd_sys_script_exec_t /domains/wiki.ucsf.bkslab.org/htdocs/extensions
chcon -R -t httpd_user_script_exec_t /usr/share/pear
chcon -R -t httpd_user_script_exec_t /usr/share/php
chcon -R -t httpd_user_script_exec_t /usr/share/mysql (?)
setsebool -P httpd_can_sendmail 1

Debugging:

sestatus
getsebool -a | grep httpd

HOW I GOT SELINUX WORKING RIGHT FOR USER WEBSITES:

chcon -R -t httpd_log_t logs
chcon -R -t httpd_user_content_t public_html
chcon -R -t httpd_config_t tdemers.ucsf.bkslab.org.conf
chcon -R -t httpd_user_script_exec_t /usr/share/pear
chcon -R -t httpd_user_script_exec_t /usr/share/php
chcon -R -t httpd_user_script_exec_t /usr/share/mysql (?)
setsebool -P httpd_can_sendmail 1
setsebool -P httpd_can_network_connect on
setsebool -P httpd_can_network_connect_db on
setsebool -P httpd_enable_homedirs on 
2097148404 1572864000 2097152000 1269939

on alpha

cd /nfs/db4/dbraw/zinc
chcon system_u:object_r:nfs_t:s0 ??

rebuild, etc