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.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Google's SwiftShader Released
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Interview with Patrick Volkerding
- Managing Linux Using Puppet
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- SuperTuxKart 0.9.2 Released
- Tech Tip: Really Simple HTTP Server with Python
- Parsing an RSS News Feed with a Bash Script