This section describes the example security policy configuration that has been developed for the Security-Enhanced Linux. At a high level, the goals of the example security policy configuration are to demonstrate the flexibility and security of the mandatory access controls and to provide a simple working system with minimal modifications to applications. The example security policy configuration consists of a combination of Role-Based Access Control (RBAC) [11] and Type Enforcement [8]. The configuration draws from the Domain and Type Enforcement (DTE) configuration described in [26], although it uses a different configuration language described in [16].
The example security policy configuration defines a set of Type Enforcement domains and types. Each process has an associated domain, and each object has an associated type. The policy configuration specifies the allowable accesses by domains to types and the allowable interactions among domains. It specifies what program types can be used to enter each domain and the allowable transitions between domains. It also specifies automatic transitions between domains when certain program types are executed. These transitions ensure that system processes and certain programs are placed into their own separate domains automatically.
The configuration also defines a set of roles. Each process has an associated role. All system processes run in the system_r role. Two roles are currently defined for users, user_r for ordinary users and sysadm_r for system administrators. These user roles are initially set by the login program and can be changed by a newrole program similar to the su program.
The policy configuration specifies the set of domains that can be entered by each role. Each user role has an associated initial login domain, the user_t domain for the user_r role and the sysadm_t domain for the sysadm_r role. This initial login domain is associated with the user's initial login shell. As the user executes programs, transitions to other domains may automatically occur to support changes in privilege. Often, these other domains are derived from the user's initial login domain. For example, the user_t domain transitions to the user_netscape_t domain and the sysadm_t domain transitions to the sysadm_netscape_t domain when the netscape program is executed to restrict the browser to a subset of the user's permissions.
Figure 4 shows a portion of the policy configuration that allows the administrator domain (sysadm_t) to run the insmod program to insert kernel modules. The insmod program is labeled with the insmod_exec_t type and runs in the insmod_t domain. The first rule allows the sysadm_t domain to run the insmod program. The second rule allows the sysadm_t domain to transition to the insmod_t domain. The third rule allows the insmod_t domain to be entered by the insmod program and to execute code from this program. The fourth rule allows the insmod_t domain to inherit and use file descriptors from the sysadm_t domain. The fifth rule allows the insmod_t domain to use the CAP_SYS_MODULE capability. The last rule allows the insmod_t domain to send the SIGCHLD signal to sysadm_t when it exits.
From this small portion of the policy configuration, it is clear that the flexibility of the mandatory access controls also yields a corresponding increase in the complexity of managing the security policy. Creating and maintaining a configuration to meet a set of security requirements and verifying that the configuration is consistent with those requirements can be a challenging task. In order for SELinux to be widely deployed and used, a collection of base policy configurations must be developed to meet common sets of security requirements to allow its use by end users with no security expertise. Furthermore, higher-level configuration languages and policy analysis tools are needed to address these challenges.
The security policy configuration controls various forms of raw access to data. The policy configuration defines distinct types for kernel memory devices, disk devices, and /proc/kcore. It defines separate domains for processes that require access to these types, such as klogd_t and fsadm_t.
The configuration protects the integrity of the kernel. The policy configuration defines distinct types for the boot files, module object files, module utilities, module configuration files and sysctl parameters, and it defines separate domains for processes that require write access to these files. As illustrated by the example in Figure 4, the configuration defines separate domains for the module utilities, and it restricts the use of the module capability to these domains. It only allows a small set of privileged domains to transition to the module utility domains.
The integrity of system software, system configuration information and system logs is protected by the configuration. The policy configuration defines distinct types for system libraries and binaries to control access to these files. It only allows administrators to modify system software. It defines separate types for system configuration files and system logs and defines separate domains for programs that require write access.
The configuration confines the potential damage that can be caused through the exploitation of a flaw in a process that requires privileges, whether a system process or privilege-enhancing (setuid or setgid) program. The policy configuration places these privileged system processes and programs into separate domains, with each domain limited to only those permissions it requires. Separate types for objects are defined in the policy configuration as needed to support least privilege for these domains.
Privileged processes are protected from executing malicious code. The policy configuration defines an executable type for the program executed by each privileged process and only allows transitions to the privileged domain by executing that type. When possible, it limits privileged process domains to executing the initial program for the domain, the system dynamic linker, and the system shared libraries. The administrator domain is allowed to execute programs created by administrators as well as system software, but not programs created by ordinary users or system processes.
The configuration ensures that the administrator role and domain cannot be entered without user authentication. The policy configuration only allows transitions to the administrator role and domain by the login program, which requires the user to authenticate before starting a shell with the administrator role and domain. It prevents transitions to the administrator role and domain by remote logins to prevent unauthenticated remote logins via .rhosts files. A newrole program was added to permit authorized users to enter the administrator role and domain during a remote login session, and this program re-authenticates the user. To provide confidentiality of secret authentication information, the policy configuration labels the shadow password file with its own type and restricts the ability to read this type to authorized programs such as login and su.
Ordinary user processes are prevented from interfering with system processes or administrator processes. The policy configuration only allows certain system processes and administrators to access the procfs entries of processes in other domains. It controls the use of ptrace on other processes, and it controls signal delivery between domains. It defines separate types for the home directories of ordinary users and the home directories of administrators. It ensures that files created in shared directories such as /tmp are separately typed based on the creating domain. It defines separate types for terminals based on the owner's domain.
The configuration protects users and administrators from the exploitation of flaws in the netscape browser by malicious mobile code. The policy configuration places the browser into a separate domain and limits its permissions. It defines a type that users can use to restrict read access by the browser to local files, and it defines a type that users can use to grant write access to local files.
