|Linux Security Technology | |
SELinux, an implementation of Mandatory Access Control (MAC) in the Linux kernel, adds the ability to administratively define policies on all subjects (processes) and objects (devices, files, and signaled processes). This mechanism is in the Linux kernel, checking for allowed operations after standard Linux Discretionary Access Controls DAC are checked.
Security-Enhanced Linux (SELinux) is a Linux feature that provides a mechanism for supporting access control security policies, including United States Department of Defense-style ...view middle of the document...
A Linux kernel integrating SELinux enforces mandatory access-control policies that confine user programs and system servers to the minimum amount of privilege they require to do their jobs. This reduces or eliminates the ability of these programs and daemons to cause harm when compromised (via buffer overflows or misconfigurations, for example). This confinement mechanism operates independently of the traditional Linux access control mechanisms. It has no concept of a "root" super-user, and does not share the well-known shortcomings of the traditional Linux security mechanisms (such as a dependence on setuid/setgid binaries).
The security of an unmodified Linux system depends on the correctness of the kernel, all the privileged applications, and each of their configurations. A problem in any one of these areas may allow the compromise of the entire system. In contrast, the security of a modified system based on the Security-enhanced Linux kernel depends primarily on the correctness of the kernel and its security policy configuration. While problems with the correctness or configuration of applications may allow the limited compromise of individual user programs and system daemons, they do not pose a threat to the security of other user programs and system daemons or to the security of the system as a whole.
SELinux users and roles are not related to the actual system users and roles. For every current user or process, SELinux assigns a three string context consisting of a role, user name, and domain (or type). This system is more flexible than normally required: as a rule, most of the real users share the same SELinux username, and all access control is managed through the third tag, the domain. Circumstance for when the user is allowed to get into a certain domain must be configured in the policies. The command runcon allows for the launching of a process into an explicitly specified context (user, role and domain), but SELinux may deny the transition if it is not approved by the policy configuration.
Typical policy rules often consist of explicit permissions; which domains the user must possess to perform certain actions with the given target (read, execute, or, in case of network port, bind or connect), and so on. More complex mappings are also possible, involving roles and security levels. A typical policy consists of a mapping (labeling) file, a rule file, and an interface file, that define the domain transition. These three files must be compiled together with the SELinux tools to produce a single policy file. The resulting policy file can be loaded into the kernel, making it active. Loading and unloading policies does not require a reboot. The policy files are either hand written or can be generated from the more user friendly SELinux management tool. They are normally tested in permissive mode first, where violations are logged but allowed. The audit2allow tool can be used later to produce additional rules that extend the...