Security-Enhanced Linux

Security-Enhanced Linux (SELinux) is an implementation of mandatory access control using Linux Security Modules (LSM) in the Linux kernel, based on the principle of least privilege. It is not a Linux distribution, but rather a set of modifications that can be applied to Unix-like operating systems, such as Linux and BSD.

__TOC__ Primarily developed by the US National Security Agency, it was released to the open source development community on December 22, 2000. Other significant contributors include Network Associates, Secure Computing Corporation, and Tresys. Experimental ports of the FLASK/TE implementation have been made available via the TrustedBSD Project for the FreeBSD and Darwin operating systems.

From NSA Security-enhanced Linux Team:

"NSA Security-enhanced Linux is a set of patches to the Linux kernel and some utilities to incorporate a strong, flexible mandatory access control (MAC) architecture into the major subsystems of the kernel. It provides a mechanism to enforce the separation of information based on confidentiality and integrity requirements, which allows threats of tampering and bypassing of application security mechanisms to be addressed and enables the confinement of damage that can be caused by malicious or flawed applications. It includes a set of sample security policy configuration files designed to meet common, general-purpose security goals."

Security-enhanced Linux is a FLASK implementation integrated in some versions of the Linux kernel with a number of utilities designed to demonstrate the value of mandatory access controls to the Linux community and how such controls could be added to Linux. Such a kernel contains architectural components prototyped in the Fluke operating system. These provide general support for enforcing many kinds of mandatory access control policies, including those based on the concepts of type enforcement, role-based access control, and multi-level security. Observers of operating system security research may recall DTOS, a Mach-derived Distributed Trusted Operating System, on which Flask was based, as well as Trusted Mach, a research project from Trusted Information Systems that was influential in the design and implementation of DTOS. Those interested in Type Enforcement may also be interested in Domain and Type Enforcement.

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 merged with the 2.6 series Linux Kernel.

Features

Clean separation of policy from enforcement
Well-defined policy interfaces
Independent of specific policies and policy languages
Independent of specific security label formats and contents
Individual labels and controls for kernel objects and services
Caching of access decisions for efficiency
Support for policy changes
Controls over process initialization and inheritance and program execution
Controls over file systems, directories, files, and open file descriptions
Controls over sockets, messages, and network interfaces
Controls over use of "capabilities"

Implementations

SE Linux is available with commercial support as part of Red Hat Enterprise Linux version 4. The supported policy in RHEL4 is the targeted policy which aims for maximum ease of use and thus isn't as restrictive as it might be. Future versions of RHEL will have more restrictive policies.

In community supported Linux distributions it has been available in Fedora Core since version 2, it is part of Hardened Gentoo, and work is proceeding on making it part of Debian SUSE Slackware ^*," target="_blank" >Ubuntu[http://www.ubuntulinux.org/wiki/SELinux, and others.

Criticism

Some administrators, developers, and security experts have criticized SELinux as too complex to set up and administer. Critics say that due to its complexity, even experienced users are likely to configure SELinux in an unsafe manner or disable it altogether, leaving the system vulnerable to attacks. Supporters of SELinux say that it simply reflects, and provides greater control over, the complexity of the underlying operating system.^*

Some have criticized SELinux for its use of inode labeling rather than pathnames as the basis for its access control. Such criticism represents a misunderstanding of Unix heritage and internals; the access control enforcement mechanisms of Unix kernels have never relied upon pathnames as their basis, as paths are ambiguous identifiers in Unix systems and do not identify the real objects (the inodes). Just as Linux discretionary access control (DAC) uses the inode attributes (file owner, group, and mode) as the basis for its enforcement, so SELinux likewise uses extended attributes of the inode as the basis for its access control. Note that administrators specify paths as part of SELinux configuration (mapping pathname regular expressions to file security contexts in the file_contexts configuration) and as arguments to utilities like chcon that are analogous to chown/chmod. But the kernel mechanism does not internally use paths. Proponents of SELinux argue that it would not make sense to do so in a Unix system, especially in a system like Linux that blends Unix concepts with Plan9 concepts like per-process namespaces and bind mounts.

Quotes

"Let me assure you that this action by the NSA was the crypto-equivalent of the Pope coming down off the balcony in Rome, working the crowd with a few loaves of bread and some fish, and then inviting everyone to come over to his place to watch the soccer game and have a few beers. There are some things that one just never expects to see, and the NSA handing out source code along with details of the security mechanism behind it was right up there on that list." --Larry Loeb ^*

External links

Operating system security | Linux security software | National Security Agency

Gourt Home::Gourt :: Security-Enhanced Linux

Features

Implementations

Criticism

See also

Quotes

External links