Jump to content

Security-Enhanced Linux: Difference between revisions

From Wikipedia, the free encyclopedia
Content deleted Content added
External links: fixed obsolete link
→‎Usage: grammar fix and clarification
Line 47: Line 47:


== Usage ==
== Usage ==
SELinux can potentially control all users, processes and daemons with very precise specifications which activities are allowed for every member. However currently it is mostly used to confine [[Daemon (computer software)|daemons]] like database engines or web servers that have more clearly defined data access and activity rights. Confined daemon may not be able to do more harm even when compromised. Ordinary users often run in the unconfined domain, not restricted by SELinux but still restricted by the classic Linux access rights.
SELinux can potentially control all users, processes and daemons with very precise specifications which activities are allowed for every member. However currently it is mostly used to confine [[Daemon (computer software)|daemons]] like database engines or web servers that have more clearly defined data access and activity rights. A confined daemon that becomes compromised is thus limited in the harm it can do. Ordinary user processes often run in the unconfined domain, not restricted by SELinux but still restricted by the classic Linux access rights.


==Implementations==
==Implementations==

Revision as of 08:47, 28 July 2010

The SELinux administrator in Fedora 8

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 system kernels, such as Linux and that of 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.

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

(SELinux has been integrated into version 2.6 series of the Linux kernel, and separate patches are now unnecessary; the above is an 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.

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.

Users, policies and security contexts

SELinux users and roles are not related to the actual system users and roles. For every current user or process, SELinux assigns a three string context consisting of a role, user name, and domain (or type). This system is more flexible than normally required: as a rule, most of the real users share the same SELinux username, and all access control is managed through the third tag, the domain. Circumstance for when the user is allowed to get into a certain domain must be configured in the policies. The command runcon allows for the launching of a process into an explicitly specified context (user, role and domain), but SELinux may deny the transition if it is not approved by the policy configuration.

Files, network ports, and other hardware also have an SELinux context, consisting of a name, role (seldom used), and type. In case of the file systems, mapping between files and the security contexts is called labelling. The labelling is defined in policy files but can also be manually adjusted without changing the policies. Hardware types are quite detailed, for instance, bin_t (all files in the folder /bin) or postgresql_port_t (PostgreSQL port, 5432). The SELinux context for a remote file system can be specified explicitly at mount time. SELinux adds the -Z switch to the shell commands ls, ps, and some others, allowing the security context of the files or process to be seen.

Typical policy rules often consist of explicit permissions; which domains the user must possess to perform certain actions with the given target (read, execute, or, in case of network port, bind or connect), and so on. More complex mappings are also possible, involving roles and security levels. A typical policy consists of a mapping (labelling) file, a rule file, and an interface file, that define the domain transition. These three files must be compiled together with the SELinux tools to produce a single policy file. The resulting policy file can be loaded into the kernel, making it active. Loading and unloading policies does not require a reboot. The policy files are either hand written or can be generated from the, user friendly, SELinux management tool. They are normally tested in permissive mode first, where violations are logged but allowed. The audit2allow tool can be used later to produce additional rules that extend the policy to allow all legitimate activities of the application being confined.

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"

Usage

SELinux can potentially control all users, processes and daemons with very precise specifications which activities are allowed for every member. However currently it is mostly used to confine daemons like database engines or web servers that have more clearly defined data access and activity rights. A confined daemon that becomes compromised is thus limited in the harm it can do. Ordinary user processes often run in the unconfined domain, not restricted by SELinux but still restricted by the classic Linux access rights.

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 GNU/Linux distributions, Fedora was one of the earliest adopters, including support for it by default since Fedora Core 2. Other distributions include support for it such as Debian as of the etch release,[1] Ubuntu as of 8.04 Hardy Heron,[2] Hardened Gentoo, and Yellow Dog Linux.

Overall, the reception to SELINUX has been mixed in the Linux community with various sys-admins preferring to stay away from it because of the usage issues [citation needed].

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

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

There was some work to provide SELinux packages for Slackware,[4] but development seems to have stagnated.

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)[citation needed].

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.

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

Unlike SELinux, AppArmor can make use of filesystems with no support for extended file attributes, such as NFS.

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

Isolation of processes can also be accomplished by mechanisms like virtualization; the OLPC project, for example, in its first implementation[5] sand-boxed individual applications in lightweight Vservers.

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

References