SELinux [Electronic resources] نسخه متنی

4.5 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

4.5.1 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.

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.

4.5.2 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

4.5.3 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.

4.5.4 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/*

4.5.5 X Problems

Most
SELinux users run servers, not desktops.
So, the community has less collective experience running the X server
under SELinux than other serverstoo 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 KDEsuch as GNOMEwhen 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.