|
|
Security-Enhanced Linux Frequently Asked Questions (FAQ) |
Security Enhanced Linux
 Employment Opportunities NSA Home Page |
Security-enhanced Linux is a research prototype of the Linux® kernel and a number of utilities with enhanced security functionality designed simply to demonstrate the value of mandatory access controls to the Linux community and how such controls could be added to Linux. The Security-enhanced Linux kernel contains new architectural components originally developed to improve the security of the Flask operating system. These architectural components provide general support for the enforcement of many kinds of mandatory access control policies, including those based on the concepts of Type Enforcement®, Role-based Access Control, and Multi-level Security. The Security-enhanced Linux kernel enforces mandatory access control policies that confine user programs and system servers to the minimum amount of privilege they require to do their jobs. When confined in this way, the ability of these user programs and system daemons to cause harm when compromised (via buffer overflows or misconfigurations, for example) is reduced or eliminated. 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. The Security-enhanced Linux's new features are designed to enforce the separation of information based on confidentiality and integrity requirements. They are designed for preventing processes from reading data and programs, tampering with data and programs, bypassing application security mechanisms, executing untrustworthy programs, or interfering with other processes in violation of the system security policy. They also help to confine the potential damage that can be caused by malicious or flawed programs. They should also be useful for enabling a single system to be used by users with differing security authorizations to access multiple kinds of information with differing security requirements without compromising those security requirements. You can download it from http://www.nsa.gov/selinux/ Security-enhanced Linux includes patches to the Linux kernel and patches to a number of standard tools and utilities. It also includes a number of new utilities, support files, and documentation. By far the easiest way to build and install Security-enhanced Linux currently is to duplicate our source trees (lsm-2.4 and selinux) and follow the instructions in selinux/README. We have provided compressed archives of our source trees, as well as several ways to build it by acquiring only our modifications from our web site (http://www.nsa.gov/selinux/). As time permits, we intend to create or modify the RPM spec files as appropriate and provide SRPM format files. Yes. You actually need to have an existing Linux system. The Security-enhanced Linux distribution is source code for a modified Linux kernel and some utilities. You must have the ability to compile a kernel and also have necessary, but unmodified system packages. Our distribution is known to install on the Red Hat distribution, and has not been tested with others. The Security-Enhanced Linux provides binary compatibility with existing Linux applications. It provides source compatibility with existing Linux kernel modules. These two categories of compatibility are discussed in detail below: We provide binary compatibility with existing applications. We have extended kernel data structures to include new security attributes, and we have added new system calls for security-aware applications. However, we have not changed any data structures visible to applications and we have not changed the interface of any existing system call, so existing applications can run unchanged if the security policy authorizes their operation. We provide source compatibility with existing kernel modules. We have not changed existing exported kernel function interfaces. However, the changes to kernel data structures require recompilation of kernel modules in order for them to be used with our kernel. The Security-enhanced Linux also provides a development support kernel configuration option (CONFIG_SECURITY_SELINUX_DEVELOP) that allows the system to be run in a permissive mode that audits but does not enforce the mandatory access controls. We are using this mode while developing the mandatory access controls and security policies in order to determine the permissions required for the system to operate. When compiled with this option, the kernel is initially permissive, and it can be toggled between being permissive and enforcing permissions at any time. New users of the Security-enhanced Linux will likely want to use this mode initially because their systems may require some permissions that are not included in the example security policy configuration, especially since the example configuration is not yet complete. For "operational" use, the kernel should be built without this option. The Security-enhanced Linux should not introduce any interoperability problems with ordinary Linux systems as long as all desired operations are authorized by the security policy configuration. At a high level the goals are to demonstrate the flexibility and security of the mandatory access controls and to provide a simple working system with minimal modifications to applications. At a lower level, the policy has a number of goals described in the policy documentation. These goals include controlling raw access to data, protecting the integrity of the kernel, system software, system configuration information and system logs, confining the potential damage that can be caused through the exploitation of a flaw in a process that requires privileges, protecting privileged processes from executing malicious code, protecting the administrator role and domain from being entered without user authentication, preventing ordinary user processes from interfering with system processes or administrator processes, and protecting users and administrators from the exploitation of flaws in their browser by malicious mobile code. Linux was chosen as the platform for the work because of its growing success and open development environment. Linux provides an excellent opportunity to demonstrate that this functionality can be successful in a mainstream operating system and, at the same time, contribute to the security of a widely used system. A Linux platform also offers an excellent opportunity for this work to receive the widest possible review and perhaps provide the foundation for additional security research by others. The Information Assurance Research Office of the NSA is responsible for carrying out the research and advanced development of technologies needed to enable the NSA to provide the solutions, products, and services to achieve Information Assurance for information infrastructures critical to U.S. National Security interests. Creating a viable secure operating system remains a critical research problem. Our goal is the creation of an efficient architecture that provides requisite support for security, executes programs in a way that is largely transparent to the user, and is attractive to vendors. We believe an essential step in attaining this goal is to show how mandatory access controls can be successfully integrated into a mainstream operating system. Researchers in the Information Assurance Research Office of the National Security Agency (NSA) worked with Secure Computing Corporation (SCC) to develop a strong, flexible mandatory access control architecture based on Type Enforcement, a mechanism first developed for the LOCK system. The NSA and SCC developed two Mach-based prototypes of the architecture: DTMach and DTOS (http://www.cs.utah.edu/flux/dtos). The NSA and SCC then worked with the University of Utah's Flux research group to transfer the architecture to the Fluke research operating system. During this transfer, the architecture was enhanced to provide better support for dynamic security policies. This enhanced architecture was named Flask (http://www.cs.utah.edu/flux/flask). The NSA is now integrating the Flask architecture into the Linux operating system to transfer the technology to a larger developer and user community. No. The phrase "Trusted Operating System" generally refers to an operating system that provides sufficient support for multilevel security and evidence of correctness to meet a particular set of government requirements. Security-enhanced Linux incorporates useful ideas from these systems but focuses upon mandatory access controls. It is expected that this work would be combined with other efforts (e.g., auditing and documentation) to construct a "trusted" system. The initial focus of Security-enhanced Linux development has been to create useful functionality that delivers tangible protection benefits in a wide range of real-world environments in order to demonstrate the technology. The notion of a secure system includes many attributes (e.g., physical security, personnel security, etc.) and Security-enhanced Linux addresses only a very narrow set of these attributes (i.e., mandatory access controls in the operating system). Put another way, "secure system" means safe enough to protect some real world information from some real world adversary that the information owner and/or user care about. Security-enhanced Linux is only a research prototype that is intended to demonstrate mandatory controls in a modern operating system like Linux and thus is very unlikely to meet any interesting definition of secure system. We do believe that the technology demonstrated in Security-enhanced Linux will be valuable to people that are building secure systems. The goal of this project has been to add mandatory access controls and make minimal changes to Linux. This latter goal greatly limits what can be done to increase assurance, so there has been no work focused upon increasing the assurance of Linux. On the other hand, the enhancements are based upon previous work to design a high assurance security architecture and most of those design principles carry over to Security-enhanced Linux. Security-enhanced Linux has not been evaluated and there are no current plans to have it evaluated. Security-enhanced Linux is not designed to address a complete set of security concerns as represented by a protection profile. Although it would be possible to evaluate its current functionality, we believe such an evaluation would have limited value. We do look forward to insightful reviews and critiques of the work as part of working with the Linux development community. We also hope to work with others to incorporate this technology into a more complete system that would be a more appropriate and useful target of evaluation. (For more information about CCEVS evaluation, visit their web site at http://niap.nist.gov/cc-scheme/.) No, we did not look for or find any vulnerabilities in the course of our work. We only changed enough to add our new mechanisms. Security-enhanced Linux is not part of any currently approved version of Linux and has no special or additional approval for government use over any other version of Linux. The security-enhanced Linux has a well-defined architecture for flexible mandatory access controls that has been experimentally validated through several prototype systems (DTMach, DTOS, Flask). Detailed studies have been performed of the ability of the architecture to support a wide variety of security policies and are available under http://www.cs.utah.edu/flux/dtos and http://www.cs.utah.edu/flux/flask. The architecture provides fine-grained controls over many kernel abstractions and services that are not controlled by other systems. Some of the distinctive characteristics of the Security-enhanced Linux system are:
All source code found on this site is released under the same terms and conditions as the original sources. For example, the patches to the Linux kernel, patches to many existing utilities, and new programs and libraries available here are released under the terms and conditions of the GNU General Public License (GPL). The patches to some existing utilities and libraries available here are released under the terms and conditions of the BSD license. There are no additional export controls for Security-enhanced Linux over any other version of Linux. For obvious reasons, NSA does not comment on operational uses. NSA's position has not changed. NSA continues to believe that the terms and conditions of the GNU General Public License govern the use, copying, distribution, and modification of SELinux. See the NSA Press Release of 2 January 2001. NSA initiatives in enhancing software security cover both proprietary and open source software, and we have successfully used both proprietary and open source models in our research activities. NSA's work to enhance the security of software is motivated by one simple consideration: Use our resources as efficiently as possible to give NSA's customers the best possible security options in the most widely employed products. The objective of the NSA research program is to develop technologic advances that can be shared with the software development community through a variety of transfer mechanisms. NSA does not favor or promote any specific software product or business model. Rather, NSA is promoting enhanced security. We have a set of web pages http://www.nsa.gov/selinux/ which will serve as our primary way of publishing information about Security-enhanced Linux. If you have an interest in Security-enhanced Linux, we encourage you to join the developers' mailing list, look at the source code, and provide your feedback (or code). To join the developers' mailing list, selinux@tycho.nsa.gov, send your request to: Majordomo@tycho.nsa.gov. As the body of your request put "subscribe selinux". This is a short list (in no particular order) of some of the many tasks remaining to be done. It is expected that research in the above-identified areas of technology will continue. However, this list of expected research shall not be considered as a request for proposal or otherwise construed as a commitment by the National Security Agency to anyone for the procurement of equipment, services, or any obligation. The National Security Agency reserves the right to not pursue research in any area identified above or to discontinue, at any time, research in progress in any of these areas. We hope to attract thoughtful comments and contributions from many members of the Linux development community. All comments and contributions sent to the selinux@tycho.nsa.gov mailing list will be considered for inclusion in future releases. NSA is not soliciting proposals for follow-on work at this time. We intend to deal with questions via the mailing list, selinux@tycho.nsa.gov but we may not be able to answer every question related to a specific site. The Security-enhanced Linux prototype was developed in conjunction with research partners from NAI Labs, Secure Computing Corporation (SCC), and the MITRE Corporation. Researchers at the NSA implemented the security architecture in the major subsystems of the Linux kernel, including mandatory access controls for operations on processes, files, and sockets. NAI Labs is working with the NSA in further developing and configuring the Security-enhanced Linux system, including the development of additional kernel mandatory access controls and the creation of a general purpose security policy configuration. The security policy configuration drew from some preliminary configuration work by SCC as a starting point, and it also drew from NAI Labs' prior Domain and Type Enforcement (DTE) configuration work. SCC, MITRE and NAI Labs are also assisting the NSA in developing application security policies and enhanced utility programs for the system. We encourage you to visit our web pages, read the documentation and past research papers as well as participate in our mailing list, selinux@tycho.nsa.gov. |
