Security-Enhanced Linux

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Wibbble (talk | contribs) at 12:04, 18 November 2006 (RV linkspam). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Jump to navigation Jump to search

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.

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."

(SELinux has been integrated into version 2.6 series of the Linux kernel, and separate patches are now unnecessary; the above is a historical quote.)

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.

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

SELinux 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 is not as restrictive as it might be. Future versions of RHEL will have more restrictive policies.

In community supported Linux distributions, SELinux is implemented in EnGarde Secure Linux [1], it has been implemented in Fedora Core since version 2, it is part of Hardened Gentoo, and work is proceeding on making it part of Debian[2], SUSE[3], Slackware[4], Ubuntu[5], 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.[6]

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 Plan 9 from Bell Labs concepts like per-process namespaces and bind mounts.

See also

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 [7]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Security-Enhanced_Linux&oldid=88607261"