Security-Enhanced Linux in Software

Printer ANSI/AIM Code 39 in Software Security-Enhanced Linux

hough numerous security tools exist for protecting specific services, as well as user information and data, no tool has been available for protecting the entire system at the administrative level Security-Enhanced Linux is a project to provide built-in administrative protection for aspects of your Linux system Instead of relying on users to protect their files or on a specific network program to control access, security measures are built into the basic file management system and the network access methods All controls can be managed directly by an administrator as part of Linux system administration Security-Enhanced Linux (SELinux) is a project developed and maintained by the National Security Agency (NSA), which chose Linux as its platform for implementing a secure operating system Most Linux distributions have embraced SELinux and incorporated it as a standard feature of its distribution Detailed documentation is available from resources listed in Table 17-1, including sites provided by the NSA and SourceForge Also check your Linux distribution s site for any manuals, FAQs, or documentation on SELinux Linux and Unix systems normally use a discretionary access control (DAC) method for restricting access In this approach, users and the objects they own, such as files, determine permissions The user has complete discretion over the objects he or she owns The weak point in many Linux/Unix systems has been the user administrative accounts If an attacker managed to gain access to an administrative account, they would have complete control over the service the account managed Access to the root user would give control over the entire system, all its users, and any network services it was running To counter this weakness, the NSA set up a mandatory access control (MAC) structure Instead of an all-ornothing set of privileges based on accounts, services and administrative tasks are compartmentalized and separately controlled with policies detailing what can and cannot be done Access is granted not just because one is an authenticated user, but when specific security criteria are met Users, applications, processes, files, and devices can be given only the access they need to do their job, and nothing more

The Flask architecture organizes operating system components and data into subjects and objects Subjects are processes: applications, drivers, system tasks that are currently running Objects are fixed components such as files, directories, sockets, network interfaces, and devices For each subject and object, a security context is defined A security context is a set of

Part V:

Resource NSA SELinux NSA SELinux FAQ SELinux at sourceforgenet Writing SELinux Policy HOWTO NSA SELinux Documentation Configuring SELinux Policy SELinux Reference Policy Project TABLE 17-1 SELinux Resources

Location nsagov/selinux nsagov/selinux/info/faqcfm selinuxsourceforgenet Accessible from "SELinux resources at sourceforge" link at selinuxsourceforgenet nsagov/selinux/info/docscfm Accessible from NSA SELinux Documentation http://osstresyscom/projects/refpolicy

security attributes that determines how a subject or object can be used This approach provides very fine-grained control over every element in the operating system as well as all data on your computer The attributes designated for the security contexts and the degree to which they are enforced are determined by an overall security policy The policies are enforced by a security server Distributions may provide different preconfigured policies from which to work For example, Fedora provides three policies, each in its own package: strict, targeted, and mls, all a variation of a single reference policy SELinux uses a combination of the Type Enforcement (TE), Role Based Access Control (RBAC), and Multi-Level Security (MLS) security models Type Enforcement focuses on objects and processes like directories and applications, whereas Role Based Access Enforcement controls user access For the Type Enforcement model, the security attributes assigned to an object are known as either domains or types Types are used for fixed objects such as files, and domains are used for processes such as running applications For user access to processes and objects, SELinux makes use of the Role Based Access Control model When new processes or objects are created, transition rules specify the type or domain they belong to in their security contexts With the RBAC model, users are assigned roles for which permissions are defined The roles restrict what objects and processes a user can access The security context for processes will include a role attribute, controlling what objects it can assess The new Multi-Level Security (MLS) adds a security level, containing both a sensitivity and capability value Users are given separate SELinux user identities Normally these correspond to the user IDs set up under the standard Linux user creation operations Though they may have the same name, they are not the same identifiers Standard Linux identities can be easily changed with commands like setuid and su Changes to the Linux user ID will not affect the SELinux ID This means that even if a user changes his or her ID, SELinux will still be able to track it, maintaining control over that user