introduction to SELinux

This article is a slightly cleaned up port from Wikipedia; I am not the author but I am including this as a introduction to SELinux as I will be posting some articles over the next few days with various SELinux configuration examples. I will also soon have an AppArmor series that showcases the differences between the two systems - This following content was brought over as it appeared on 11/10/2009 from - http://en.wikipedia.org/wiki/Selinux


Security-Enhanced Linux (SELinux) is a Linux feature that provides a mechanism for supporting access control 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). The germinal concepts underlying SELinux can be traced to several earlier projects by the U.S. National Security Agency.


Overview

Primarily developed by the US National Security Agency, it was released to the open source development community under the GNU GPL 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 an enhanced 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.

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 an SELinux 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.

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

Implementations

SELinux is available with commercial support as part of Red Hat Enterprise Linux (RHEL) version 4 and all future releases. This presence is also reflected in corresponding versions of CentOS. 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, Ubuntu as of 8.04, Fedora since version 2, Hardened Gentoo, and Yellow Dog Linux.

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

As of version 11.1, openSUSE contains SELinux 'basic enablement'.SUSE Linux Enterprise 11 will feature SELinux as a 'technology preview'.


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—courtesy of its profound creativity and resultant opacity to typically technically junior NCSC staff—was ultimately unpublished. Sponsored by Chet Coates and Mario Tinto of the NSA's National Computer Security Center, and managed by Dr. Charles Testa and Bruce Wilner of Infosystems Technology (Greenbelt, MD; later, Falls Church, VA), the crucial architects of the TRUSIX project — and members of its Modelling Subcommittee — were Steve Bunch, Dr. Frank Knowles, Dr. J. Eric Roskos, Larry Wehr, and Bruce Wilner. (Testa and Wilner also, under NSA auspices, briefly chaired the joint DoD/DOE Labeling Working Group — which counted among its membership such early TCSEC luminaries as David Bell, Marvin Schaefer [former chief scientist, DoD Computer Security Center], 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.

Novell's AppArmor 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. Also AppArmor can make use of filesystems with no support for extended file attributes, such as NFS while SELinux cannot.