SELinux

Troubleshooting SELinux

SELinux is generally stable and free of trouble. But sometimes, particularly during the initial period when a system administrator is unfamiliar with SELinux, problems crop up. The following five subsections provide troubleshooting tips that address the most common problems encountered. These problems are classified into the following five categories:

• Boot problems

• Local login problems

• Program execution problems

• Daemon problems

• X problems

Boot Problems

It’s relatively common to misconfigure or otherwise break an SELinux system in a way that prevents it from booting. If you find that you’ve done so, try to boot into permissive mode (enforcing=0) or with SELinux disabled (selinux=0). If your kernel does not support these options, boot the system using a non-SELinux kernel, such as one residing on rescue media. Generally, you can then troubleshoot and repair the problem.

Tip

If you boot with SELinux disabled or by using a non-SELinux kernel, the system will likely create unlabeled files or disturb existing file labels during your session. To repair the damage, you should reboot into permissive mode, relabel the filesystems, reboot, and relabel the filesystems once again.

Local Login Problems

Another relatively common problem is inability to log into the system. A likely cause is that the user’s home directory is not labeled or is labeled with an incorrect security context. You can fix this problem by using the fixfiles utility:

fixfiles restore

Alternatively, if you’re confident that only one user’s home directory is badly labeled, you can fix the problem by using the setfiles utility:

cd /etc/security/selinux/src/policy
setfiles file_contexts/file_contexts /home/bill

Program Execution Problems

If an application program fails to work properly, the program is likely attempting to violate the security policy. To troubleshoot the problem, inspect the system log for SELinux denial messages related to the application. If the system is running in enforcing mode but temporarily running the system in permissive mode would not pose an unacceptable risk, you may find it convenient to switch modes. Doing so should enable the program to execute properly and should provide log messages that point out the problem.

To avoid the problem, you may simply need to start the program in an appropriate security context. Alternatively, you may need to modify the security policy. Chapter 5-Chapter 9 provide you with the information and techniques for doing so.

Daemon Problems

Problems with daemons, particularly crond and SSHd are also relatively common. cron jobs often fail to start because the associated scripts are not properly labeled. You can relabel the troublesome scripts by issuing the fixfiles command:

fixfiles restore

or by issuing the setfiles command:

cd /etc/security/selinux/src/policy
setfiles file_contexts/file_contexts cron_files

where cron_files is the path of the script or scripts to be relabeled.

If you can’t log in via SSH, consider the following possibilities:

The user account may not be properly configured.

Verify that you can log into the user account from the console.

The user account is not associated with staff_r or user_r.

If the user account is associated only with the sysadm_r role, the user won’t be able to log in via SSH.

The SSH daemon is not running in the proper context.

SSH should run in the security context root:system_r:sshd_t. Use ps -Z to determine the context actually used. If the context is not correct, restart the process using the correct context. For instance, issue the command:

run_init /etc/init.d/sshd restart

More generally, programs started by init scripts may fail to operate correctly. This problem is generally due to improper labeling of one or more init scripts. You can relabel the scripts by issuing the fixfiles command:

fixfiles restore

or by issuing the setfiles command:

cd /etc/security/selinux/src/policy
setfiles file_contexts/file_contexts /etc/init.d/*

X Problems

Most SELinux users run servers, not desktops. So, the community has less collective experience running the X server under SELinux than other servers—too little, it seems, to ensure trouble-free operation. So, you may find it prudent to avoid using X and SELinux together. However, SELinux is achieving a new level of popularity with the release of Fedora Core 2, and many Fedora Core 2 users operate desktops. Moreover, an experimental branch of Xorg improves integration between X and SELinux by implementing policy restrictions on X objects such as windows, frames, and so on. We can reasonably expect that the quality of the X-SELinux experience will soon improve. In the meantime, I can offer some tips based on my experience and that of others.

If you’re running X as the root user, you may find that the system hangs. However, you shouldn’t run X as the root user whether your system runs SELinux or not. So, to avoid such system hangs, log in as a user other than the root user. Alternatively, if you insist on running X as the root user, transitioning to the sysadm_r:sysadm_t role before starting X may avoid the system hangs.

When using KDE, you may find that several graphical applications or features don’t work properly. This occurs because KDE starts a variety of executables with the same process name, kdeinit. No simple fix exists for such problems, since a simple fix would entail loosening security to an unacceptable extent. You may find it more convenient to use a desktop other than KDE—such as GNOME—when running SELinux.

A workaround is to log out of KDE and remove all KDE-related temporary files from /var/tmp. Then log into KDE and see if the problems persist.