If you use the targeted SELinux policy (which is delivered and on by default), you can still administer Linux as you always have. To use the strict SELinux policy, you must change the way you administer your Linux system. If you are new to Linux, turning on the strict policy in SELinux is not a good place to start. Besides being fairly new and somewhat unstable, the extra amount of thought required to learn SELinux makes it most appropriate for environments that must be highly secure.
The following procedure describes the software packages you need to use SELinux and starts you off working with the default targeted policy.
Support for SELinux is built into the Linux 2.6 kernel, as well as a range of supporting operating system features that come with Fedora Core 3. To use SELinux in Fedora Core 3, however, during installation you must enable it.
Enabling SELinux during Fedora Core installation is done on the Firewall Configuration screen. When that screen appears during installation, make sure that Active is selected next to the Enable SELinux box.
With SELinux enabled, you also have to install the following software packages:
checkpolicy — Contains the SELinux policy compiler named checkpolicy. Use this package to build or check policies for SELinux. Using checkpolicy, you create binary policy files from policy configurations and parameters in a policy.conf file. (Type man checkpolicy to read about checkpolicy.)
libselinux — Contains the application programming interface for SELinux applications. It includes components used by application programs to check SELinux status.
policycoreutils — Contains basic utilities needed to operate an SELinux system. Commands include fixfiles (to check and possibly correct security attributes on file systems), restorecon (to set security attributes for selected files), audit2allow (to translate messages from /var/log/messages to rules that SELinux can use), newrole (open a shell in a new role), load_policy (to load a policy file), run_init (to run an init script using the correct context), sestatus (to check whether SELinux is currently enabled), and setfiles (to set the security contexts of files).
selinux-doc — Contains a lot of SELinux documentation that is stored in the /usr/share/SELinux directory.
selinux-policy-strict — Contains the sample policy file used to incorporate the strict SELinux policy into a running Linux system.
selinux-policy-strict-sources — Contains source packages needed to compile the strict SELinux policy file.
selinux-policy-targeted — Contains the sample policy file used to incorporate the targeted SELinux policy into a running Linux system, as well as contexts files and the booleans file needed to make run-time changes to SELinux.
selinux-policy-targeted-sources — Contains source packages needed to compile the targeted SELinux policy file.
setools — Contains tools for managing parts of a running policy that define what access users have to different components of the Linux system.
After Fedora Core is installed, you can check the /etc/selinux/config file (which is linked to /etc/sysconfig/selinux) to see if SELinux is enabled and, if so, which policies are in effect. That file sets two critical variables for a Fedora system configured to use SELinux:
SELinux State — The SELINUX variable sets the state of SELinux. If you enable SELinux during Fedora installation this starts out as SELINUX=enforcing (which causes security policies for SELinux to be enforced). If SELinux is disabled during installation, SELINUX=disabled is set instead. A third choice is to set SELINUX=permissive, which prints warnings based on the policies you have set, instead of enforcing them.
SELinux Policy Type — The SELINUXTYPE variable indicates the type of policy to use. SELINUX=targeted protects only selected network daemons (as set in files located in the /etc/selinux/targeted directory). SELINUX=strict puts the entire Fedora system under SELinux control (see files in /etc/selinux/strict).
For most practical purposes, if you use SELinux you will want to enable the SELINUX- targeted policy (which is the default). While not locking down all Fedora components under SELinux, the targeted policy does lock down those daemon processes that are most critical to protect from attacks. Standard Linux security protects everything else in the operating system.
You can override your default settings to place SELinux into permissive mode from the Linux boot prompt by adding the following to the end of the kernel line from the GRUB screen when you boot Fedora Core:
With SELinux in permissive mode (setenforce 0), you can still login and use the system, with any potentially devastating permission failures simply resulting in error messages. If SELinux is in permissive mode, you can likewise return SELinux to enforcing mode from the boot prompt by typing setenforce 1 instead.
There are many tools for checking the status of SELinux on your Fedora Core system. To check whether or not SELinux is enabled, type the following:
# sestatus -v SELinux status: disabled
The output just displayed shows that SELinux is not enforced on the current system. If SELinux were enabled, the output would look more like the following:
SELinux status: enabled SELinuxfs mount: /selinux Current mode: enforcing Policy version: 18 Policy booleans: dhcpd_disable_trans inactive httpd_disable_trans inactive httpd_enable_cgi active httpd_enable_homedirs active httpd_ssi_exec active . . . Process contexts: Current context: root:system_r:unconfined_t Init context: user_u:system_r:unconfined_t /sbin/mingetty user_u:system_r:unconfined_t /usr/sbin/sshd user_u:system_r:unconfined_t File contexts: Controlling term: root:object_r:tty_device_t /etc/passwd system_u:object_r:etc_t /etc/shadow user_u:object_r:etc_t /bin/bash system_u:object_r:shell_exec_t . . .
Besides showing that SELinux is enabled and running in enforcing mode, this output shows the current boolean features, process contexts and file contexts that are set.
To see and change basic SELinux settings from a graphical interface, you can open the Security Level Configuration window. From the red hat menu, select System Settings ® Security Level (or run system-config-securitylevel as root from a Terminal window). When the window opens, select the SELinux tab. Figure 28-1 shows that window.
Figure 28-1: Change SELinux policy settings using the Security Level Configuration window.
On the Security Level Configuration window (SELinux tab), you can change whether or not SELinux is enabled on the next reboot and select whether enforcing or permissive (test policyonly) are active for your policy. You can also turn off or on selected features associated with Apache, Name Service (DNS), and NIS. For other services (under the Transition heading), you can choose to disable SELinux protection.
Changing the policy type between targeted and strict requires that you also relabel the entire file system. Changing policy should never be done lightly. If you do decide to change policy through the Security Level Configuration window, that change also requires that the file system be relabeled. By changing the policy through this window, the file system will be relabeled automatically the next time you reboot your computer.
Relabeling the file system can be a long and time-consuming activity. Again, remember that changing policies is a major change to your operating system. The more nodes there are in your file system, the longer it will take to relabel your file system the next time you boot your computer.
You can check the security context in which you are operating using the id command with the -Z option. The following example shows that your current context is the root user, your role is the system_r role, and the type is unconfined_t.
# id -Z root:system_r:unconfined_t
SELinux is capable of turning out a lot of error messages. By default, those messages are directed to the /var/log/messages file. Because the file contains messages from many different services, you can use the seAudit window (type seaudit from a Terminal window) to view messages strictly related to SELinux. Figure 28-2 shows an example of the SeAudit window.
Figure 28-2: View messages related to SELinux activity in the seAudit window.
There are ways of changing your SELinux policies either during runtime or permanently, so they take effect when you reboot.
To change some values related to SELinux in real time, you can use the Security Level Configuration window (SELinux tab). From that window, look at the services named in the Modify SELinux Policy box. Under Apache, Name Service, and NIS, there are settings you can select or unselect to indicate whether or not you want to have those settings be on or off. Any changes take effect immediately.
If you would like to make more permanent changes to your policies, you can modify the source files (from either strict or targeted policy sets) and rebuild your policy file. To update the policy sources you must have those source files installed (either through the selinux- policy-targeted-sources or selinux-policy-targeted-sources package).
The SELinux Policy Customization Tool (SePCuT) gives you a visual way of editing and rebuilding your SELinux policies. To open the SePCuT window, type sepcut as root user from a Terminal window. Select the policy by choosing Policy ® Choose policy directory. For the directory (when prompted), choose either /etc/selinux/targeted/src/policy or /etc/selinux/strict/src/policy. Figure 28-3 shows an example of the SePCuT window showing a file_contexts file.
Figure 28-3: Change and rebuild SELinux policies from the SePCuT window.
From the SePCuT window, select the policy modules. From this screen, you can see the Program Policy modules, including Apache, BIND, DHCPD and other services. Select the module that interests you and modify any rule you like in the Type Enforcement Rules box.
To save changes you made to a policy file using SePCuT, select File ® Save. Then, you can rebuild your current policy by selecting Policy ® Reload current policy.
When you have the policies the way you want them, you should make sure that your SELinux configuration is set to run in permissive mode. This will let you see error messages from potential access failures without an operation actually failing. This gives you the opportunity to correct errors while still having a functioning system.