Kernel Korner - NSA Security Enhanced Linux
NSA Security Enhanced Linux has its roots in the distributed trusted operating system (DTOS) and Flask (Flux advanced security kernel) architecture. The DTOS Project was a collaborative effort between the US National Security Agency (NSA) and Secure Computing Corporation (SCC) in the early and mid-1990s. The goal was to provide stronger operating system security mechanisms than those provided by standard security methods. The Flask architecture was the result of a joint effort between the NSA, SCC and the University of Utah's Flux Project, which was “enhanced to provide better support for dynamic security policies” (www.cs.utah.edu/flux/flask, “Flask: Flux Advanced Security Kernel” by Stephen Smalley, NAI Labs, December 26, 2000).
SE Linux implements mandatory access control, or MAC, while regular UNIX systems employ discretionary access control, or DAC. With DAC, users can control what access is applied to objects they own at their discretion. On a UNIX system, for example, they can use the chmod command to change permissions on directories they own. With MAC, access control is decided by a more authoritative user who configures security policies that determine what access rights an object possesses. If a policy is preventing Bob from accessing Alice's home directory, and Alice runs chmod 777 on her home directory, Bob still would not be able to access it.
When utilizing MAC, processes are run with a minimum amount of privilege, and a compromised process cannot grant other processes inappropriate access to its own resources. This reduces the amount of damage that might occur if a dæmon was compromised. Security decisions are based on a number of factors, such as the role of the user, what type of program is being run, how trusted that program is and the secrecy level or integrity of the data being accessed.
SE Linux is an implementation of flexible, fine-grained mandatory access controls in the Linux kernel that is now implemented using the LSM framework (see “Using the Kernel Security Module Interface” by Greg Kroah-Hartman, LJ, November 2002). In its current implementation, the LSM interface supports only restrictive access controls. Therefore, if the standard UNIX permissions deny an operation, SE Linux cannot permit it. SE Linux generally is used to apply additional restrictions to a system that employs UNIX permissions, and it is quite capable of enforcing all necessary access controls on its own. However, it is strongly recommended that a combination of UNIX permissions and SE Linux be used for “defense in depth” on production servers. SE Linux is comprised of a kernel patch and patches to utility programs such as login and cron.
The NSA is responsible for official releases. A number of other people outside the NSA also contribute code to the project. Packages are maintained constantly for the Debian stable and unstable releases. As SE Linux is licensed under the GPL, anyone can contribute and make her own modifications. SE Linux can be used on 2.4.19 kernels and above, and at the time of this writing, May 2003, it is being redeveloped for the 2.5 kernel.
As previously mentioned, SE Linux is comprised of a kernel patch and modified utility programs. The modified utilities ensure that all files on the system possess the correct security context. Modified versions of utilities, such as login, cron and logrotate, and programs, such as ps and ls, are available. With login, for example, it is crucial to have the correct security contexts when a user logs in to the system. If not, he might not be able to log in at all.
Installing the login package is covered in the Getting Started with SE Linux HOWTO (see Resources) and is beyond the scope of this article. Forgetting to install the login package during the SE Linux installation, however, results in not having the right type assigned to the terminal device from which you are logging in after a reboot, which renders you unable to log in. An unmodified login program also runs a shell in a security context that is denied access to files in the user's home directory. The patches for login and cron, for example, tell the kernel which security context to use. The actual enforcement of these measures is done by the kernel. Labeling is imperative, hence the need for some modified programs. It is possible to create your own security policies that provide basic levels of protection without having to to install modified packages, but the default configuration provides finer-grained security.
|A Project to Guarantee Better Security for Open-Source Projects||Aug 27, 2015|
|Concerning Containers' Connections: on Docker Networking||Aug 26, 2015|
|My Network Go-Bag||Aug 24, 2015|
|Doing Astronomy with Python||Aug 19, 2015|
|Build a “Virtual SuperComputer” with Process Virtualization||Aug 18, 2015|
|Firefox Security Exploit Targets Linux Users and Web Developers||Aug 17, 2015|
- Concerning Containers' Connections: on Docker Networking
- A Project to Guarantee Better Security for Open-Source Projects
- Problems with Ubuntu's Software Center and How Canonical Plans to Fix Them
- My Network Go-Bag
- Firefox Security Exploit Targets Linux Users and Web Developers
- Doing Astronomy with Python
- Build a “Virtual SuperComputer” with Process Virtualization
- diff -u: What's New in Kernel Development
- Three More Lessons
- August 2015 Issue of Linux Journal: Programming