SELinux Frequently Asked Questions (FAQ)
We have attempted to answer some of the questions most frequently asked about the SELinux project. The questions are currently divided into two general areas. All questions and answers are on this page. You may use the index below to jump directly to a specific question.
- What is Security-enhanced Linux (SELinux)?
- What does Security-enhanced Linux give me that standard Linux can't?
- What is it good for?
- How can I get a copy?
- What does your release include?
- Can I install Security-enhanced Linux on an existing Linux system?
- How compatible is Security-enhanced Linux with unmodified Linux?
- What are the goals of the example security policy configuration?
- Why was Linux chosen as the base platform?
- Why did you do this work?
- How does it relate to previous NSA OS research?
- Is Security-enhanced Linux a Trusted Operating System?
- Is it secure?
- What have you done to increase the assurance?
- Will Security-enhanced Linux be evaluated by the CCEVS?
- Did you try to fix any vulnerabilities?
- Is it approved for government use?
- How is it different from other efforts?
- What are the licensing restrictions on it?
- Are there any export controls on it?
- Does NSA have plans to use it internally?
- Does Secure Computing Corporation's 26 July 2002 Statement of Assurance alter NSA's position that SELinux was made available under the GNU General Public License?
- Does NSA favor open source software?
- Does NSA favor Linux?
What is Security-enhanced Linux?
Security-enhanced Linux (SELinux) is a reference implementation of the Flask security architecture for flexible mandatory access control. It was created to demonstrate the value of flexible mandatory access controls and how such controls could be added to an operating system. The Flask architecture has been subsequently mainstreamed into Linux® and ported to several other systems, including the Solaris operating system, the FreeBSD® operating system, and the Darwin kernel, spawning a wide range of related work. The Flask architecture provides 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.
What does Security-enhanced Linux give me that standard Linux can't?
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.
What is it good for?
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.
How can I get a copy?
Many Linux distributions include SELinux support already integrated either as a default feature or as an optional package. The core SELinux userland code is available on GitHub. End users should generally use the packages provided by their distribution.
What does your release include?
The NSA SELinux release includes the core SELinux userland code. SELinux support is already included in the mainline Linux 2.6 kernel available from kernel.org. The core SELinux userland code consists of a library for binary policy manipulation (libsepol), a policy compiler (checkpolicy), a library for security-aware applications (libselinux), a library for policy management tools (libsemanage), and several policy-related utilities (policycoreutils).
In addition to a SELinux-enabled kernel and the core SELinux userland code, you will need a policy and certain SELinux-patched userspace packages to use SELinux. A policy may be obtained from the SELinux reference policy project.
Can I install Security-enhanced Linux on an existing Linux system?
Yes, you can install just the SELinux modifications on an existing Linux system or you can install a Linux distribution that already includes SELinux support. SELinux consists of a SELinux-enabled Linux kernel, a core set of libraries and utilities, some modified userland packages, and a policy configuration. To install it on an existing Linux system that lacks SELinux support, you must have the ability to compile the software and also have other necessary system packages. If your Linux distribution already includes SELinux support, you don't need to build or install the NSA SELinux release.
How compatible is Security-enhanced Linux with unmodified Linux?
Security-enhanced Linux provides binary compatibility with existing Linux applications and with existing Linux kernel modules, but some kernel modules may require modification to interact properly with SELinux. These two categories of compatibility are discussed in detail below:
- Application compatibility
SELinux provides binary compatibility with existing applications. We have extended kernel data structures to include new security attributes, and we have added new API 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.
- Kernel module compatibility
Originally, SELinux only provided source compatibility for existing kernel modules; it was necessary to recompile such modules against the modified kernel headers to pick up the new security fields added to the kernel data structures. Since LSM and SELinux are now integrated into the mainline Linux 2.6 kernel, SELinux now provides binary compatibility with existing kernel modules. However, some kernel modules may not interact well with SELinux without modification. For example, if a kernel module directly allocates and sets up a kernel object without using the normal core kernel initialization functions, then the kernel object may lack proper security information. Some kernel modules may also lack proper security controls over their operations; any existing calls to the kernel capable or permission functions will trigger SELinux permission checks as well, but finer-grained controls or additional controls may be necessary to enforce MAC policies.
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.
- Application compatibility
What are the goals of the example 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.
Why was Linux chosen as the base platform?
Linux was chosen as the platform for the initial reference implementation for this 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.
Why did you do this work?
The National Information Assurance Research Laboratory of the National Security Agency is responsible for carrying out the research and advanced development of technologies needed to enable 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.
How does it relate to previous NSA OS research?
Researchers in the National Information Assurance Research Laboratory of 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. NSA and SCC developed two Mach-based prototypes of the architecture: DTMach and DTOS (http://www.cs.utah.edu/flux/dtos/). 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/). NSA has now integrated the Flask architecture into the Linux operating system to transfer the technology to a larger developer and user community.
Is Security-enhanced Linux a Trusted Operating System?
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. The initial focus of Security-enhanced Linux development was to create useful functionality that delivers tangible protection benefits in a wide range of real-world environments in order to demonstrate the technology. SELinux by itself is not a trusted operating system, but provides a crucial security feature - mandatory access control - needed for a trusted operating system. SELinux has been integrated into Linux distributions that have been evaluated against the Labeled Security Protection Profile. Information about validated products and products in evaluation can be found at http://niap-ccevs.org/.
Is it secure?
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 intended to demonstrate mandatory controls in a modern operating system like Linux and thus is very unlikely by itself 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.
What have you done to increase the assurance?
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.
Will Security-enhanced Linux be evaluated by the CCEVS?
By itself, 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 alone, we believe such an evaluation would have limited value. However, we have worked with others to incorporate this technology into Linux distributions that have been evaluated and distributions that are in evaluation. Information about validated products and products in evaluation can be found at http://niap-ccevs.org/.
Did you try to fix any vulnerabilities?
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.
Is it approved for government use?
Security-enhanced Linux has no special or additional approval for government use over any other version of Linux.
How is it different from other efforts?
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:
- Clean Separation of Policy from Enforcement
- Well-Defined Policy Interfaces
- 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
- Controls over Process Initialization and Inheritance and Program Execution
- Controls over File Systems, Directories, Files, and Open File Descriptions
- Controls over Sockets, Messages, and Network Interfaces
- Controls over Use of "Capabilities"
What are the licensing restrictions on it?
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 and patches to many existing utilities available here are released under the terms and conditions of the GNU General Public License (GPL).
Are there any export controls on it?
There are no additional export controls for Security-enhanced Linux over any other version of Linux.
Does NSA have plans to use it internally?
For obvious reasons, NSA does not comment on operational uses.
Does Secure Computing Corporation's 26 July 2002 Statement of Assurance alter NSA's position that SELinux was made available under the GNU General Public License?
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.
Does NSA favor open source software?
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.
Does NSA favor Linux?
As noted above, NSA does not favor or promote any specific software product or platform; NSA is only promoting enhanced security. The Flask architecture demonstrated in the SELinux reference implementation has been ported to several other operating systems, including Solaris, FreeBSD, and Darwin, has been ported to the Xen hypervisor, and has been applied to applications such as the X Window System, GConf, D-BUS and PostgreSQL. The concepts of the Flask architecture are broadly applicable to a wide range of systems and environments.
- What is Security-enhanced Linux?
How do we plan to interact with the Linux community?
We have a set of web pages on NSA.gov 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, see the SELinux Developers' Mailing List page.
Who can contribute?
SELinux is now maintained and further developed by the Linux and open source software community.
Is NSA funding any follow-on work?
NSA is not soliciting proposals for follow-on work at this time.
What type of support is available?
We intend to deal with questions via the mailing list, firstname.lastname@example.org but we may not be able to answer every question related to a specific site.
Who helped? What did they do?
The Security-enhanced Linux prototype was developed by NSA in conjunction with research partners from NAI Labs, Secure Computing Corporation (SCC), and the MITRE Corporation. Since the initial public release, many other contributions have followed. See a list of contributors.
How can I learn more?
We encourage you to visit our web pages, read the documentation and past research papers as well as participate in our mailing list, email@example.com.
- How do we plan to interact with the Linux community?
Linux® is a registered trademark of Linus Torvalds in the United States and other countries.
FreeBSD® is a registered trademark of the FreeBSD Foundation.
Solaris and OpenSolaris are trademarks or registered trademarks of Sun Microsystems, Inc in the United States and other countries.
Xen is a trademark of Xen Source, Inc in the United States and other countries.
MITRE is a registered trademark of The MITRE Corporation
NAI is a trademark of Networks Associates Technology, Inc.
Secure Computing is a registered trademark of Secure Computing Corporation
Type Enforcement is a registered trademark of Secure Computing Corporation