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:
Local login problems
Program execution problems
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.
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.
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:
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
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.
with daemons, particularly
are also relatively common.
often fail to start because the associated scripts are not properly
labeled. You can relabel the troublesome scripts by issuing the
cd /etc/security/selinux/src/policy setfiles file_contexts/file_contexts
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:
Verify that you can log into the user account from the console.
If the user account is associated only with the
sysadm_r role, the user won’t be
able to log in via SSH.
SSH should run in the security context
-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
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:
or by issuing the setfiles command:
cd /etc/security/selinux/src/policy setfiles file_contexts/file_contexts /etc/init.d/*
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
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.