Section 13.1. SELinux Configuration and Policy Management Files
13.1. SELinux Configuration and Policy Management FilesSELinux includes files that allow the management of SELinux specific additions, including the policy. This includes setting which policy to use when multiple policies are installed, label management files, and configuration files for SELinux applications and utilities. Note The files we describe in this chapter are based on a Fedora Core 4 (FC4) system. There are subtle differences with a RHEL4 and more significant improvements in an FC5 system. We highlight these differences as appropriate throughout this chapter. 13.1.1. The SELinux Configuration File (/etc/selinux/config)The SELinux configuration file, /etc/selinux/config, controls which policy will be loaded during the next system boot, and in what mode the system will run. We can determine the current SELinux system state using the sestatus command. Listing 13-1 shows an example of the config file. Listing 13-1. Listing of /etc/selinux/conf File
This file controls two configuration settings: the SELinux mode and the active policy. The SELinux mode (determined by the SELINUX option on line 6) can be set to enforcing, permissive, or disabled. In enforcing mode, the policy is fully enforced. This is the primary mode of SELinux and should be used in all operational systems that require the enhanced security of SELinux. In permissive mode, the policy rules are not enforced. Instead, denials are audited, and otherwise SELinux generally does not impact the security of the system. This mode is useful for debugging and testing a policy. In disabled mode, the SELinux kernel mechanism is completely turned off. A system may only be put into disabled mode when booting before the policy is loaded. This mode differs from permissive mode which has the SELinux kernel features operating but not denying any access (just auditing). In disabled mode, SELinux will not perform any action. This mode is only necessary in extreme circumstances (for example, when a policy error prevents you from even logging in, which can occur even in permissive mode) or if we truly do not want SELinux to operate. Warning Be careful about switching between enforcing and permissive modes, or disabling and enabling SELinux (something you might commonly do in a development or test machine). Quite often, you can cause file labeling inconsistencies when you go back to enforcing mode. (Not to mention that you will have turned off your system's main security enhancement feature!) We discuss how to fix file labeling problems later in this chapter. The mode set in the SELinux configuration file is used by init to configure SELinux before it loads the initial policy as part of the boot process. The SELINUXTYPE option in the SELinux configuration file tells init which policy to load during system initialization. The string used for the setting must match the directory name where the binary version of the policy you want to use is stored. For example, throughout this book, we use a strict policy as an example. So, we set the option as SELINUXTYPE=strict and make sure that the policy we want the kernel to use is in /etc/selinux/strict/policy/. If we had created our own custom policy, called custom_policy, we would set the option as SELINUXTYPE=custom_policy and make sure that our compiled policy is in /etc/selinux/custom_policy/policy/. FC and RHEL systems provide a graphical tool (system-config-securitylevel) that enables us to set the options in the SELinux configuration file without having to edit the file directly (see Figure 13-1). The first two check boxes in this tool set the SELINUX option for us. The Policy Type drop-down box allows us to choose an active policy from the installed policies. Figure 13-1. Red Hat security level configuration tool 13.1.2. The Policy DirectoriesAs of FC3 (and RHEL4), every policy installed on a system has its own subdirectory under the /etc/selinux/ directory. The subdirectory name corresponds to the name of the policy (for example, strict, targeted, refpolicy, and so on) and is used in the SELinux configuration file to tell the kernel which policy to load on boot. All path references in this section are relative to a policy directory path (that is, /etc/selinux/[policy]/). Here is a sample directory listing for /etc/selinux/ from an FC4 machine: # ls -lZ /etc/selinux -rw-r--r-- root root system_u:object_r:selinux_config_t config drwxr-xr-x root root system_u:object_r:selinux_config_t strict drwxr-xr-x root root system_u:object_r:selinux_config_t targetedAs you can see, two policy directories are installed on our system: strict and targeted. Notice that the directory and the policy subdirectories are labeled with the type selinux_config_t. This is the type traditionally applied to binary policies and related support files. You can use apol to examine the rules for this type and get an idea of what programs and utilities may change policy files.
Each policy subdirectory must follow a convention in the files they contain and how the files are labeled. This convention is used by various system utilities to help manage the policy. Generally, any well designed policy source tree will install the policy files correctly (as will properly constructed package installation scripts). Following is a listing of our strict policy directory, which is typical of any installed policy: # ls -lZ /etc/selinux/strict -rw------- root root system_u:object_r:selinux_config_t booleans -rw------- root root root:object_r:selinux_config_t booleans.local drwxr-xr-x root root system_u:object_r:default_context_t contexts drwxr-xr-x root root system_u:object_r:policy_config_t policy drwx------ root root system_u:object_r:policy_src_t src drwxr-xr-x root root system_u:object_r:selinux_config_t usersThe src/ directory is not required for a running system. It optionally contains the installed policy source tree (either the example policy or the reference policy source tree we discussed in Chapters 11, "Original Example Policy," and 12, "Reference Policy"). The actual monolithic binary policy file is stored in the .policy/ directory, in a file named policy.[ver], where [ver] is the version of the policy binary (for example, policy.19). This is the file that is loaded into the kernel during system boot. We discuss the remaining files and directories in the following sections. 13.1.2.1. Installed Booleans FilesChapter 9, "Conditional Policies," discussed how Booleans are managed in an SELinux system. An SELinux policy defines default values for all Booleans. The booleans file provides the distribution the ability to set persistent changes to these default values. The values in booleans override the policy defaults when the policy is loaded or the system is booted. The booleans.local file provides additional persistent values that override both the policy default values and the distribution persistent values. You should review Chapter 9 for how to set and control Boolean values. There is also a manual page, man 8 booleans, that provides a quick summary on the use of Booleans for FC and RHEL systems. In FC5, where the booleans file is no longer present but the booleans.local file remains for local changes (although changes are made through semanage/libsemanage and not from directly changing the file), distribution defaults are now managed in the policy itself. Red Hat sets their defaults in the policy sources, thereby removing the need to have a separate distribution file to override the policy defaults. Note In RHEL4 systems, the booleans.local file does not exist. Rather, the only ability to override policy default values (other than changing the policy itself) is the booleans file in the policy directory. The problem with a single file is that Red Hat uses this file to set distribution defaults, and utilities such as rpm may overwrite it destroying any local changes. In FC4, the booleans.local file was added to allow local changes that will not be effected by package managers. In Fedora Core 5, where the booleans file is no longer present but the booleans.local file remains for local changes (though changes are made through semanage/libsemanage and not from directly changing the file). Distribution defaults are now managed in the policy itself; Red Hat sets their defaults in the policy sources thereby removing the need to have a separate distribution file to override the policy defaults. The system-config-securitylevel utility (see Figure 13-1) provides a graphical interface to change the local persistent values (that is, the booleans.local file). The items in the Modify SELinux Policy list box of this tool correspond to defined policy Booleans. The Boolean values can also be changed with the command-line tool setsebool and viewed with the setatus and getsebool commands (see Appendix D, "SELinux Commands and Utilities"). 13.1.2.2. Application and File Security ContextsThe contexts/ subdirectory, in an installed policy directory, contains various files that help system services and utilities manage file security context labeling. They also contain default security contexts for login processes. In general, these files would only be changed by a policy developer, but occasionally an administrator may have need to modify one of them. Here we summarize the purpose of some of these files:
Each line in this file contains a role/type pair representing the security context of the login process followed by one or more role/type pairs that represent the default security context for the user's initial login process. For example, here are two typical lines for an SELinux system: system_r:local_login_t staff_r:staff_t user_r:user_t sysadm_r:sysadm_t system_r:sshd_t user_r:user_t sysadm_r:sysadm_t The first line represents the local login process (login via its type login_t), and the second a Secure Shell login (ssh via its type sshd_t). The login process is determined by the first role/type pair on a line. For example, the assumption in this file is that the login process (for local logins) runs with a security context that has system_r as its role and local_login_t as its type. In that case, the subsequent list of role/type pairs on the same line will be used as the default security contexts (minus the user identifier) for a user login. The first role/type pair in the list of default security context that is authorized for the user in the policy is used as the default security context. This file does not authorize a user for a role or a type; only the policy may do that (see Chapter 6, "Roles and Users"). So, for example, in the local login case for our example default_contexts file, if administrators log in locally (administrators are generally users authorized for both staff_r:staff_t and sysadm_r:sysadm_t), their default security context will be staff_r:staff_t even though they are authorized for sysadm_r:system_t. An administrator could later change their security context (for example, using the newrole command) because they are authorized for both, but the default is the "staff" set of privileges. Notice for an ssh login, the default is the "sysadm" set of privileges. Note that these defaults may be overridden for a specific user if there is a contexts/users/[USER] file (see the following).
13.1.2.3. SELinux User DefinitionsThe two files in the user/ directory were added to support better user management in an SELinux system without having to change the policy. Both files have the same format. Specifically, they list policy user statements as discussed in Chapter 6.
The load_policy utility reads these files and changes the binary policy before loading it into the kernel. (The change is only to the in-memory version of the policy; the on-disk binary policy does not change.) In general, for either file, if the user already exists in the policy file (that is, hard-coded in the original policy sources), the role associations are changed. Otherwise, the user is added to the policy before it is loaded into the kernel. 13.1.2.4. The SELinux FilesystemThe SELinux pseudo filesystem provides the primary control interface between the SELinux kernel-space Linux Security Module (LSM) and userspace programs (see Figure 3-2 in Chapter 3). This filesystem is usually mounted on /selinux/. Many SELinux utilities and APIs (provided by the libselinux library) use the SELinux filesystem to access the LSM module. In this section, we examine some of the files that may be of interest to an administrator. Most of the files in this filesystem exist to support APIs in libselinux and are not discussed here. The recommended way to use these files is through the more stable libselinux APIs and the tools that use that library, and not directly.
|
EAN: 2147483647
Pages: 154