Integrating Flexible Support for Security Policies into the Linux OperatingSystemPeter Loscocco, NSA, [email protected] Smalley, NAI Labs, [email protected] protection mechanisms of current mainstream op-erating systems are inadequate to support confidentialityand integrity requirements for end systems. Mandatoryaccess control (MAC) is needed to address such require-ments, but the limitations of traditional MAC have in-hibited its adoption into mainstream operating systems.The National Security Agency (NSA) worked with Se-cure Computing Corporation (SCC) to develop a flexi-ble MAC architecture called Flask to overcome the lim-itations of traditional MAC. The NSA has implementedthis architecture in the Linux operating system, produc-ing a Security-Enhanced Linux (SELinux) prototype, tomake the technology available to a wider communityand to enable further research into secure operating sys-tems. NAI Labs has developed an example security pol-icy configuration to demonstrate the benefits of the ar-chitecture and to provide a foundation for others to use.This paper describes the security architecture, securitymechanisms, application programming interface, secu-rity policy configuration, and performance of SELinux.1 IntroductionEnd systems must be able to enforce the separationof information based on confidentiality and integrity re-quirements to provide system security. Operating sys-tem security mechanisms are the foundation for ensur-ing such separation. Unfortunately, existing mainstreamoperating systems lack the critical security feature re-quired for enforcing separation: mandatory access con-trol (MAC) [17]. Instead, they rely on discretionary ac-cess control (DAC) mechanisms. As a consequence, ap-plication security mechanisms are vulnerable to tamper-ing and bypass, and malicious or flawed applications caneasily cause failures in system security.DAC mechanisms are fundamentally inadequate forstrong system security. DAC access decisions are onlybased on user identity and ownership, ignoring othersecurity-relevant information such as the role of the user,the function and trustworthiness of the program, and thesensitivity and integrity of the data. Each user has com-plete discretion over his objects, making it impossible toenforce a system-wide security policy. Furthermore, ev-ery program run by a user inherits all of the permissionsgranted to the user and is free to change access to theuser’s objects, so no protection is provided against ma-licious software. Typically, only two major categoriesof users are supported by DAC mechanisms, completelytrusted administrators and completely untrusted ordinaryusers. Many system services and privileged programsmust run with coarse-grained privileges that far exceedtheir requirements, so that a flaw in any one of theseprograms can be exploitedto obtain complete system ac-cess.By adding MAC mechanisms to the operating system,these vulnerabilities can be addressed. MAC access de-cisions are based on labels that can contain a variety ofsecurity-relevant information. A MAC policy is definedby a system security policy administrator and enforcedover all subjects (processes) and objects (e.g. files, sock-ets, network interfaces) in the system. MAC can supporta wide variety of categories of users on a system, and itcan confine the damage that can be caused by flawed ormalicious software.Traditional MAC mechanisms have typically beentightly coupled to a multi-level security (MLS) [7] pol-icy which bases its access decisions on clearances forsubjects and classifications for objects. This traditionalapproach is too limiting to meet many security require-ments [8, 9, 10]. It provides poor support for data andapplication integrity, separation of duty, and least priv-ilege requirements. It requires special trusted subjectsthat act outside of the access control model. It fails totightly control the relationship between a subject and thecode it executes. This limits the ability of the system tooffer protection based on the function and trustworthi-ness of the code, to correctly manage permissions re-quired for execution, and to minimize the likelihood ofmalicious code execution.To address the limitations of traditional MAC, the Na-tional Security Agency (NSA), with the help of SecureComputing Corporation (SCC), began researching newways to provide strong mandatory access controls thatcould be acceptable for mainstream operating systems.An important design goal for the NSA was to provideflexible support for security policies, since no singleMAC policy model is likely to satisfy everyone’s secu-rity requirements. This goal was achieved by cleanlyseparating the security policy logic from the enforce-ment mechanism. Through the development of twoMach-based prototypes, DTMach [12] and DTOS [20],the NSA and SCC developed a strong, flexible securityarchitecture. Although high assurance was not a goal ofthe research, formal methods were applied to the designto help validate the security properties of the architec-ture [23, 24]. Likewise, performance optimization wasnot a goal, but significant steps were taken in the archi-tecture to minimize the performance overhead normallyassociated with MAC. NSA and SCC then worked withthe University of Utah’s Flux research group to trans-fer the architecture to the Fluke research operating sys-tem [25]. During the transfer,what has become the Flaskarchitecture was enhanced to provide better support fordynamic security policies.The NSA created Security-Enhanced Linux, orSELinux for short, by integrating this enhanced archi-tecture into the Linux operating system. It has been ap-plied to the major subsystems of the Linux kernel, in-cluding the integration of mandatory access controls foroperations on processes, files, and sockets. NAI Labshas since joined the effort and has implemented sev-eral additional kernel mandatory access controls, includ-ing controls for the procfs and devpts file systems. TheMITRE Corporation and SCC have contributed to thedevelopment of some application security policies andhave modified utility programs, but their contributionsare not discussed further in this paper.Using the flexibility of SELinux, it is possible to con-figure the system to support a wide variety of securitypolicies. The system can support:separation policies that can enforce legal restric-tions on data, establish well-defined user roles, orrestrict access to classified data,containment policies
View Full Document
Unlocking...