Background
From the RedHat SELinux documentation:
Security Enhanced Linux (SELinux) provides an additional layer of system security. SELinux fundamentally answers the question: May <subject> do <action> to <object>?, for example: May a web server access files in users' home directories?
Sometimes we ask our users to do the following actions to test if SELinux is the cause of the issue:
Do you have SELinux enabled? You can check by running sestatus. If it is, can you try setting it to permissive and test again; the command is sudo setenforce 0 to switch to permissive, then sudo setenforce 1 to switch back to enforcing.
This is a great test to see if SELinux is the problem, but we have now disabled SELinux, which might not be the desired security strategy for the customer. Further, SELinux will revert on reboot, and the problem will reappear.
SELinux is hard to give specific instructions for because of the enormity of the project, and the variables that are hidden from us - OSes and OS patch levels, other software installed, deployment decisions not shared.
Please note: Posit can't support or recommend changes to SELinux policies. Posit provides this documentation as a service only - this document is designed to help you get started. Please refer to your Operating System documentation, and your company policy, on how to best manage SELinux in your environments.
Troubleshooting
So how do we troubleshoot in that situation? The RedHat SELinux Troubleshooting documentation is the best available, for all OSes.
These are the tools you will need to install:
deb based systems
apt install auditd setools policycoreutils policycoreutils-python \
libselinux-utils selinux-utils
rpm based systems
yum install audit setools setroubleshoot setroubleshoot-server \
policycoreutils-python-utils
Confirm that the auditd service is running:
systemctl start auditd
Then do a generic search of the audit logs:
# ausearch -m AVC,USER_AVC,SELINUX_ERR,USER_SELINUX_ERR -ts recent
An example of this can be given relatively easily - a new, vanilla, installation of Workbench on Rocky8 will allow you to log in, but will deliver you to a blank screen. If we run the above command we might see entries like:
time->Fri Mar 4 02:52:37 2022 type=PROCTITLE msg=audit(1646362357.108:51):
proctitle="/usr/lib/rstudio-server/bin/rserver" type=SYSCALL msg=
audit(1646362357.108:51): arch=c000003e syscall=42 success=no exit=-13
a0=5 a1=55c25aac3750 a2=10 a3=7ffcb5e09ea8 items=0 ppid=1 pid=971 auid=
4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
ses=4294967295 comm="rserver" exe="/usr/lib/rstudio-server/bin/rserver"
subj=system_u:system_r:init_t:s0 key=(null) type=AVC msg=audit(1646362357.108:51):
avc: denied { name_connect } for pid=971 comm="rserver" dest=5432
scontext=system_u:system_r:init_t:s0
tcontext=system_u:object_r:postgresql_port_t:s0 tclass=tcp_socket permissive=0
In this situation, we can see that the issue is that the rserver process isn't allowed access to the postgresql port.
Another that you might see looks like this:
type=USER_AVC msg=audit(1646364690.761:119): pid=1976 uid=0
auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0
msg='avc: denied { rootok } for scontext=system_u:system_r:init_t:s0
tcontext=system_u:system_r:init_t:s0 tclass=passwd permissive=0
exe="/usr/lib/rstudio-server/bin/rserver-launcher" sauid=0 hostname=?
addr=? terminal=?'
In this case, the launcher isn't able to launch as the user in question.
How to solve these issues will depend on what messages you see in the auditd logs. This command will give you suggestions on how to fix some of the problems.
sealert -l "*"
Posit recommends you make the best judgment given your security strategy and highly recommends the RedHat SELinux documentation for comprehensive descriptions.
Other resources: