Security is a difficult and complicated problem, which must be addressed at several levels. The technologies discussed in this page are mainly concerned with mandatory access control - the hardening of the system so that no component of that system may go beyond its permitted capabilities. The largest value of MAC schemes is often seen when a system component is compromised as a result of an internal bug. If the MAC system has been set up properly, the compromised application should not enable the attacker to take control of the system as a whole. It is claimed that SELinux has already mitigated some vulnerabilities in this manner.
Equally important, of course, is maintaining the integrity of the kernel itself. As the recent vmsplice() vulnerability showed, that can be a hard thing to do - we are trying to maintain a large and complex code body while being faced with capable and motivated attackers. Upcoming kernels are likely to reflect an increased interest in the use of technical means to avoid vulnerabilities - buffer overrun detection and the like. But there is no substitute for old-fashioned code auditing and review.
Contents |
AppArmor
AppArmor is a mandatory access control mechanism acquired (and open-sourced) by Novell. Like SELinux, AppArmor controls the behavior of programs with the idea of containing any potential security breaches within those programs. AppArmor differs from SELinux, however, in that it addresses a smaller set of potential threats and is intended to be much simpler to administer.
Forecast: AppArmor has run into difficulties finding its way into the mainline kernel. Certain techniques used by the patch - such as the use of pathnames for access control policies - are not entirely popular. Linus Torvalds has made it clear, though, that this approach to security is acceptable in the Linux kernel. Since then, many of the developers working on AppArmor have been laid off and have moved on to other things.
As of 2.6.31, interest in AppArmor appears to have waned considerably, with little (public) work being done. TOMOYO Linux (a module with a similar approach) has passed it and gotten into the mainline first. Unless something changes, AppArmor may never be a part of the standard kernel.
For more information:
- The AppArmor debate begins (April, 2006)
- Kernel Summit 2006: Security (July, 2006)
SMACK
The Simplified Mandatory Access Control Kernel (SMACK) is a security module designed to implement mandatory access controls in a simple manner. Like SELinux, SMACK works by attaching labels to processes, files, and other system objects and implementing rules describing what kinds of access are allowed by specific combinations of labels. Unlike SELinux, though, SMACK was designed specifically for simplicity of administration.
Forecast: SMACK was merged for the 2.6.25 kernel.
For more information:
- Smack for simplified access control (August, 2007)
- SMACK meets the One True Security Module (October, 2007)
TOMOYO Linux
TOMOYO Linux is a mandatory access control framework similar to AppArmor. Like AppArmor, it has been criticized for its use of pathnames and (to some) simplistic approach to security.
Forecast: TOMOYO Linux was merged for the 2.6.30 kernel.
For more information:
- TOMOYO Linux and pathname-based security (April, 2008)
TALPA / fsnotify
TALPA is a proposed mechanism which would support malware scanning. In short, any attempt by a process to open or read a file could be intercepted by the kernel and put on hold until a user-space process has scanned the relevant file and convinced itself that there is nothing harmful there. While few people worry about malware which affects Linux systems directly, more are concerned about Linux systems being used as a conduit through which such software could be passed on to more vulnerable systems.
Forecast: TALPA is a controversial development. Many developers question its cost and feel that the security it provides is illusory at best. On the other hand, many corporate policies require support for this kind of scanning, and the commercial products which implement it on Linux now do so in highly questionable ways. Merging TALPA would give vendors a supported way to provide this scanning functionality for those who want it.
In an effort to improve its chances of inclusion, this work was rebranded "fanotify," and it has been reworked in a way which helps to clean up filesystem notification mechanisms in the kernel in general. Most developers seem satisfied with the direction this work has taken, though some points remain. A 2.6.30 merge seems ambitions, but 2.6.31 or 2.6.32 could happen.
For more information:
- Kernel-based malware scanning (December, 2007)
- The TALPA molehill (August, 2008)
- TALPA strides forward (August, 2008)
Credential records
The credential record patch seeks to unify and separate all of the process credential information - the information which describes how a process may act on other objects in the system - into a single structure. There should not be a whole lot of user-visible results from this change beyond a system which is more secure, especially in situations where processes are performing privileged operations. Credential records are needed for some other developments, such as FS-Cache.
Forecast: The credentials work was merged for the 2.6.29 kernel.
For more information:
- Credential records (September, 2007)
Integrity measurement
IBM has been carrying a set of integrity measurement patches for a couple of years now. These patches make use of the trusted platform module (TPM) chip built into many systems to verify that system files have not been tampered with, provide remote attestation of the local software configuration, and implement multi-level integrity and access. This code can be used to implement good things (systems which can detect tampering and respond to it) and not-so-good things (DRM and locked-down systems).
Forecast: The integrity management code was merged for the 2.6.30 kernel.
For more information:
- The integrity measurement architecture (May, 2005)
- Some trusted computing security modules (November, 2005)
- Integrity management in the kernel (March, 2007)
Sandboxing
"Sandboxing" refers to the act of running specific programs in a highly-restricted environment which prevents access to most system resources. The Java virtual machine can be run as a type of sandbox. The use of sandboxes is especially interesting to web browser developers who want to be able to run code from arbitrary web sites in a secure manner.
A number of approaches to sandboxing have been proposed recently. These include Google's Native Client, an SELinux-based approach, changes to the rudimentary "secure computing" mechanism built into the Linux kernel now, and system call interception using the ftrace framework.
Forecast: Making forecasts in this area is tricky at best. Effective sandboxing is hard, and new security technologies always have a high bar to get over on their way into the kernel. There may not be a clear solution to this problem in 2009.
For more information:
- Securely renting out your CPU with Linux (January, 2005)
- Seccomp and sandboxing (May, 2009)
- Google's Native Client (June, 2009)
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.
Groups:
