Security-Enhanced Linux

From Wikipedia, the free encyclopedia

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.


Contents

[edit] Overview

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, Trusted Computer Solutions, 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.

[edit] Features

  • Clean separation of policy from enforcement
  • Well-defined policy interfaces
  • Support for applications querying the policy and enforcing access control (EG crond running jobs in the correct context)
  • 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
  • Separate measures for protecting system integrity (domain-type) and data confidentiality (MLS aka Multilevel security)
  • Very flexible policy
  • 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"

[edit] Implementations

SELinux is available with commercial support as part of Red Hat Enterprise Linux (RHEL) version 4 and all future releases. 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 targets in the targeted policy which will mean more restrictive policies.

In free community supported Linux distributions, SELinux is supported in Debian as of the etch release [1], Fedora Core since version 2, Hardened Gentoo, and Yellow Dog Linux.

It is also supported in EnGarde Secure Linux [2] which requires registration to download.

There was some work to provide SE Linux packages for SUSE[3] and Slackware[4], but development seems to have stopped (the files are old).

Ubuntu[5] has been supported and it's expected that the first Ubuntu release based on Debian/etch will have better support of SE Linux.

There has been work on other distributions such as Familiar, but some of this was ceased due to technical reasons (the Familiar work was abandoned when SE Linux needed extended attributes which were not supported in the JFFS2 filesystem).

[edit] 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. However, because SE Linux only provides restrictive controls and cannot permit an operation that Unix permissions deny, this is not possible. A further criticism is that processes can, for example, fail to start with no feedback given that it is SELinux causing the failure, resulting in significant time wasted in ascertaining the cause of the problem. 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.

[edit] See also

Portal:Free software
 Free software Portal

[edit] 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]

[edit] External links

Retrieved from "http://en.wikipedia.org../../../s/e/c/Security-Enhanced_Linux_2c2a.html"