Section 2.5. SELinux Features Familiarization

2.5. SELinux Features Familiarization

At this time, it is worthwhile to play with an SELinux system a little. For our examples, we use a Fedora Core 4 (FC4) distribution with the strict policy. Most of these examples should also work on Red Hat Enterprise Linux version 4 (RHEL4) or Fedora Core 5 (FC5). You might also be able to work with other distributions, although there may be differences. Appendix A, "Obtaining SELinux Sample Policies," describes how to obtain the policy files and other materials we use as examples throughout this book and how to configure your system accordingly.

Running in Permissive Mode

SELinux can run in permissive mode, where the access checks occur; but instead of denying unallowed access, it simply audits them. This mode is useful when first learning about SELinux, and you may want to start exploring the system in this mode. Of course, permissive mode should not be used in operational systems if you want the enhanced access security of SELinux. Note that some utilities are found in /usr/sbin, which is not normally in a regular user's path.

The simplest way to check the current mode of SELinux is to run the getenforce command. To set the system in permissive mode, run the command setenforce 0. (You must be logged in as root in the sysadm_t domain to change the system to permissive mode.) To return it to enforcing mode, run the command setenforce 1. (Because you are in permissive mode, you just need to be logged in as root to change the system to enforcing mode.)

We have already mentioned the -Z option added to some system commands. Commands such as ls and ps display the security contexts of files and processes. As an exercise, run the commands ps xZ and ls -Z /bin and examine the various security contexts for running processes and executable files.

2.5.1. Revisiting the Passwd Example

Throughout this chapter, we used the example of the shadow password file and the password program. If you examine the security context of these two files, their types should be shadow_t and passwd_exec_t, respectively. As discussed previously, passwd_exec_t is the entrypoint type for the passwd_t domain. To witness how the process of domain transitions work, walk through the following set of commands. You need two terminal windows or virtual consoles to do this walkthrough.

In the first window, run the passwd command:

$ passwd Changing password for user joe. Changing password for joe (current) UNIX password:

This starts the password program and prompts for the user's current password. Do not enter the password, but instead switch to the second terminal. In the second terminal, su to root and then run the ps command:

$ su Password: Your default context is root:sysadm_r:sysadm_t. Do you want to choose a different one? [n] # ps axZ|grep passwd user_u:user_r:passwd_t           4299 pts/1    S+     0:00 passwd

As you can see, the type of the running password program is passwd_t, as we would expect given the rules described in the examples earlier in this chapter.

Note

In a strict policy such as the one we use for our examples, a normal user (that is, a user running a shell in the user_t domain) does not have permission to read many /proc/pid entries, and as such the passwd process would not show up in the ps axZ output. That is why you need to su to root first.

2.5.2. Perusing the Policy File

In FC4 systems, the binary file containing the kernel policy is located in the well-known directory /etc/selinux/. The configuration file (config) in that directory indicates the policy to be used and loaded on boot. You can also configure the system to boot in permissive mode in this file. For our exercises, we are using FC4's strict policy, which (if installed according to Appendix A) should be here:

/etc/selinux/strict/policy/policy.[ver]

The version of the policy reflects the version of the SELinux policy compiler (checkpolicy). In our example, the version is 19. Configuring an SELinux system and creating a kernel policy file from policy sources are discussed in greater detail in Part III, "Creating and Writing SELinux Security Policies." For now, we want to look around inside the policy to see what is there.

A useful tool for examining the contents of a policy is the policy analysis tool apol created by Tresys Technology and distributed in a package of SELinux tools called SeTools (see Appendix D, "SELinux Commands and Utilities"). The SeTools package is included on most SELinux distributions. Run the command apol to determine whether the tool is present on your system. If not, Appendix D provides information on how to obtain the SeTools package.

The apol (for "analyze policy") tool is a sophisticated SELinux policy analysis tool that we use throughout the book to examine SELinux policies. For now, we want to use some of its basic features to examine aspects of the policy file. Run apol and open the strict policy file. Under the menu Query > Policy Summary, you can view a summary of the policy statistics (see Figure 2-7).

Figure 2-7. Policy summary using apol

Apol has a series of major tabs (Policy Components, Policy Rules, Analysis, and so on) that enable you to search and analyze a policy in various ways. Take some time to explore the Policy Components and Policy Rules tabs and become familiar with both portions of the policy we discussed in this chapter and the apol tool itself. You will find it useful throughout Part II, "SELinux Policy Language," to use apol to examine your policy and follow along with the examples.