| Security-enhanced Linux |
Website Links For Linux |
Information AboutSecurity-enhanced Linux |
| CATEGORIES ABOUT SECURITY-ENHANCED LINUX | |
| operating system security | |
| linux security software | |
| national security agency | |
|
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. From a puristic perspective, SELinux provides a hybrid of concepts and capabilities drawn from mandatory access controls, mandatory integrity controls, Role-based Access Controls (RBAC), and Type Enforcement Architecture . Third-party tools enable one to build a variety of security policies. FEATURES
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 since version 2, Hardened Gentoo , and Yellow Dog Linux . It is also supported in EnGarde Secure Linux {Link without Title} which requires registration to download. There was some work to provide SE Linux packages for {Link without Title} , but development seems to have stopped (the files are old). Ubuntu {Link without Title} has been supported and it's expected that the first Ubuntu release based on Debian/etch will have better support of SELinux. 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 an intellectually impressive 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 such luminaries as 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. 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. The discussion about the advantages and disadvantages of either method often revolve around which approach is more aligned with existing UNIX/Linux access control mechanisms, but UNIX and Linux use a combination of path-based and inode-based access control. 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 Vserver s. SEE ALSO
QUOTES
EXTERNAL LINKS
|
|
|