Security-Enhanced Linux

From Wikipedia, the free encyclopedia

 This article does not cite any references or sources. (November 2007)
Please help improve this article by adding citations to reliable sources. Unverifiable material may be challenged and removed.

Security-Enhanced Linux (SELinux) is a Linux feature that provides a variety of security policies, including U.S. Department of Defense style mandatory access controls, through the use of Linux Security Modules (LSM) in the Linux kernel. 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. Its architecture strives to streamline the volume of software charged with security policy enforcement, which is closely aligned with the Trusted Computer System Evaluation Criteria (TCSEC, referred to as Orange Book) requirement for trusted computing base (TCB) minimization (applicable to evaluation classes B3 and A1) but is quite unrelated to the least privilege requirement (B2, B3, A1) as is often claimed.[citation needed] The germinal concepts underlying SELinux can be traced to several earlier projects by the U.S. National Security Agency.

Contents

[edit] Overview

Primarily developed by the US National Security Agency, it was released to the open source development community on December 22, 2000 and merged into the mainline kernel 2.6.0-test3, released on 8 August 2003. 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.

From a puristic perspective, SELinux provides a hybrid of concepts and capabilities drawn from mandatory access controls, mandatory integrity controls, Role-based access control (RBAC), and type enforcement architecture. Third-party tools enable one to build a variety of security policies.

[edit] Features

  • Clean separation of policy from enforcement
  • Well-defined policy interfaces
  • Support for applications querying the policy and enforcing access control (for example, 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 descriptors
  • 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], ubuntu as of 8.04 Hardy Heron[2] , Fedora since version 2, Hardened Gentoo, and Yellow Dog Linux.

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

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

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 SELinux needed extended attributes which were not supported in the JFFS2 filesystem).

The earliest work directed toward standardizing an approach toward provision of mandatory and discretionary access controls (MAC & DAC) within a UNIX (more precisely, POSIX) computing environment can be attributed to the National Security Agency's Trusted UNIX (TRUSIX) Working Group, which met from 1987 to 1991 and published one Rainbow Book (#020A) and produced a formal model and associated evaluation evidence prototype (#020B) that was ultimately unpublished. Sponsored by Chet Coates and Mario Tinto of the NSA's National Computer Security Center, and managed by Charles Testa of Infosystems Technology, the crucial architects of the TRUSIX project — and members of its Modeling Subcommittee — were Steve Bunch, Frank Knowles, Eric Roskos, Larry Wehr, and Bruce Wilner. (Testa and Wilner also briefly chaired the NSA Labeling Subcommittee — which counted among its membership to David Bell, Marv Schaefer, and Willis Ware — as well as building Trusted RUBIX, the only relational database management system to offer B2 functionality and assurance atop a B2 POSIX platform, partially under the auspices of the United States Air Force Rome Laboratory.) Their efforts, particularly as critics of the less technically profound work of the TRUSIX Access Control List (ACL) Subcommittee, survive in the IEEE POSIX 1003.6 "security extensions for portable operating systems environments" specification.

[edit] Other systems

SELinux represents one of several possible approaches to the problem of restricting the actions that installed software can take.

The AppArmor system generally takes a similar approach to SELinux. One important difference is that it identifies file system objects by path name instead of inode. This means that, for example, a file that is inaccessible may become accessible under AppArmor when a hard link is created to it, while SELinux would deny access through the newly created hard link. On the other hand, data that is inaccessible may become accessible when applications update the file by replacing it with a new version (a frequently used technique), while AppArmor would continue to deny access to the data. (In both cases, a default policy of "no access" avoids the problem.)

While there has been considerable debate about which approach is better, there is no strong evidence as of yet that one approach is preferable to the other. However in all Unix systems UID/GID based file access decisions (that is both "Unix permissions" and POSIX ACLs) are based on inode not path. Renaming a file does not change the access that is granted to it, neither does creating a new hard link with a different name. Using a file-name based access system will give many exciting surprises when it comes to renaming files and creating hard links.

If a security policy is to be analysed to prove that it meets the required security goals then all hard links must have the same access control. Otherwise link A might allow secret data to be written and link B might allow unprivileged processes to read it.

Note also that existing access control mechanisms remain in place with either system.

SELinux and AppArmor also differ significantly in how they are administered and how they integrate into the system.

Isolation of processes can also be accomplished by mechanisms like virtualization; the OLPC project, for example, sandboxes individual applications in lightweight Vservers.

[edit] See also

Free software Portal
Linux 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 [6]
  • “...given the threat models and capabilities of the adversaries involved, that's probably appropriate... But that’s not necessarily appropriate for all users. SELINUX is so horrible to use, that after wasting a large amount of time enabling it and then watching all of my applications die a horrible death since they didn't have the appropriate hand-crafted security policy, caused me to swear off of it. For me, given my threat model and how much my time is worth, life is too short for SELinux.” — Theodore Ts’o [7]

[edit] External links