![Close [x]](http://dw1.s81c.com/i/c.gif){kind=small}
It came from out of the blue, without fanfare. The "new" National Security Agency threw out a security-enhanced version of the Linux 2.2 kernel (called SE Linux ) into the open source community. Not only that, they gave out background briefing papers on the research methodology that they used to model whether or not SE Linux was truly secure.
If you haven't been following the cryptography area lately, let me assure you that this action by the NSA was the crypto equivalent of the Pope coming down off the balcony in Rome, working the crowd with a few loaves of bread and some fishes, and then inviting everyone to come over to his place to watch the soccer game and have a few beers. There are some things that one just never expects to see, and the NSA handing out source code along with details of the security mechanism behind it was right up there on that list. Up to this point, the NSA has embodied in itself the classic Cold War paranoia imperative of the past 50 years ("If you knew what we knew, you'd agree with us"). To see it spewing source like some long-haired Stanford student was enough to make for uncontrollable twitching.
But, they seem to mean it. The distribution .tgz file contains no secret Trojan horse that reads the data on your hard disk and then sends it all back to Fort Meade. There's no way to hide a trap door in code that all can comment upon and analyze. It is true that the NSA does need a secured OS to do that voodoo that they do so well, and they seem to have plans to actually use SE Linux internally. By incorporating a commercial product called NetTop, it's been reported that the NSA will replace several physically separated computers (this implies the "air gap" method of operational security -- differing levels of security on physically separated systems) with one box running SE Linux (see Resources).
The SE Linux authors seem to have a realistic grasp of what they can do to improve security. When asked in an SE Linux mail group if the SE Linux team would be conducting a security audit of current Linux disk encryption, Peter Loscocco (one of the SE Linux authors and currently the SE Linux project leader at the NSA) replied:
"No. The goals of this project are pretty specific. We are looking to incorporate flexible mandatory access control architecture into Linux. We are not trying to find/fix bugs or to analyze security components like a crypto FS to improve on their designs. That is not to say that these activities aren't useful or needed to improve the security of Linux in general. It is just not what we have set out to do. The security of Linux will be improved by the addition of such security features as those in SE Linux.
"From the point of view of this project, our interest in cryptography is really to investigate ways that the selection of cryptographic mechanisms can be integrated with the MAC policy, applying the same principles of policy flexibility and separation of enforcement from the policy decisions. In short, we'd like to see a flexible cryptographic usage policy that is enforced just as the system security policy is. We hope to be able to make crypto mechanism selection decisions, including a decision of whether crypto is even required, based on the security contexts.
"I think that these ideas should be investigated in both file system and network implementations. Certainly, cryptography defined behind a well-defined crypto API makes this idea more feasible. Doing this for file cryptography is still something we would like to try in the future, but have no immediate plans [to do so]. However, we do have plans to build upon our previous work in this area for networking. We will be integrating IKE and IPSEC with the existing MAC policy. As this work really gets started, we'll have more to say about it.
"Again, the goals of our project are not to improve or certify existing cryptography. We are interested in providing the necessary system support to use whatever cryptography the system supports in a way that can be tied to the mandatory access-control policy. The details of the cryptography should be independent of this support, or as much so as is possible."
The SE Linux security architecture: An overview
So, how does SE Linux work? First of all, don't expect it to be ready for prime time as distributed. The authors have stated that instead of the SE Linux effort being considered to be the standard, it's an effort that should be included in the standard. The authors want mandatory access controls in the Linux kernel and that's the idea behind SE Linux. Many implementation issues remain that need to be resolved (or code written) before it can be used in the real world. Fortunately, Linux has a history of vendors that do this kind of work for a fee, and I expect to see RedHat SE Linux any day now.
The overall security architecture is called Flask, and was designed by the NSA with assistance from the University of Utah and the Secure Computing Corp. In the Flask architecture, the security policy's logic is encapsulated within a separate component of the operating system, along with a general interface for obtaining security policy decisions. This separate component is referred to as the security server, even though it's just a kernel subsystem. The SE Linux implementation of this server defines a hybrid security policy composed of Type Enforcement (TE), role-based access control (RBAC), and the optional multilevel security (MLS), widely used in military security. The policy is compiled by a separate program called checkpolicy, which is read by the security server at boot time. The file is labeled /ss_policy. This implies that the security policies are variable for each time the system boots. Policies can even change during system operation (as long as the policy is configured to allow such changes) by using the security_load_policy interface.
Flask has two policy-independent data types for security labels -- the security context and the security identifier. The security context is a variable-length string that represents the security label. The security identifier (SID) is an integer mapped by the security server to a security context. The SID serves the system as a simple handle to the actual context. It can only be interpreted by the security server. Flask does the actual system binding through constructs called object managers. These handle SIDs and security contexts opaquely, and do not touch the attributes of a security context. Any change in format should not require changes be made to the object managers.
Figure 1
Source: The Flask Security Architecture: System Support for Diverse Security Policies by Ray Spencer (Secure Computing Corporation), Stephen Smalley, Peter Loscocco (National Security Agency), Mike Hibler, David Andersen, and Jay Lepreau (University of Utah). (See Resources).
The security server will only provide an SID for security contexts that contain legal combinations of user, role, type, and the optional MLS range. "Legality" is established by a security policy configuration (which will be addressed later in this article).
In general, the object managers consult the security server to get an access decision based on a pair of labels (the subject's and the object's) and an object's class. The class is an integer that identifies the kind of object it is (for example, a regular file, a directory, a process, a UNIX domain socket, or a TCP socket). The permissions in the vector are usually defined by the services the object can support and the security policy that is being enforced. The access vector permissions are interpreted based on the class, because different services exist for different kinds of objects. For example, the permission bit in the access vector that is used represents the 'unlink' permission for files, which is also used to represent the 'connect' permission for sockets. Vectors can be cached in the Access Vector Cache (AVC) or stored with the object so that the object managers don't have to flood the security server with requests for decisions that have already been performed.
Object managers must also define a mechanism for assigning labels to their objects. The control policy that specifies how the manager uses security decisions in the flow of services must also be defined and implemented by the manager. In the case of policy changes, the object manager must define the handling routines that will be called. In all cases, the object manager must treat the security context of the object as an opaque string. In this way, there should be no policy-specific logic incorporated into the object managers.
Figure 2
Source: The Flask Security Architecture: System Support for Diverse Security Policies by Ray Spencer (Secure Computing Corporation), Stephen Smalley, Peter Loscocco (National Security Agency), Mike Hibler, David Andersen, and Jay Lepreau (University of Utah). (See Resources).
Runtime changes in security policy are possible. If they occur, the security server updates the SID mapping by canceling SIDs that are no longer authorized and resets the AVC.
Figure 3
Source: The Flask Security Architecture: System Support for Diverse Security Policies by Ray Spencer (Secure Computing Corporation), Stephen Smalley, Peter Loscocco (National Security Agency), Mike Hibler, David Andersen, and Jay Lepreau (University of Utah). (See Resources).
Files are special instantiations of the object class. New files inherit the same type as those in their parent directory. A permanent integer SID (PSID) is associated with a file, which is then mapped to the security label in a partitioned table. This table (which separates the object/PSID and PSID/security label mappings) is loaded into memory when the file system is mounted. It's updated in memory (and on disk) when a new security label is applied to the file. This allows the inode-based PSID/object map to follow the file if it is remotely mounted or even if it is renamed by the file system.
Figure 4
Source: The Flask Security Architecture: System Support for Diverse Security Policies by Ray Spencer (Secure Computing Corporation), Stephen Smalley, Peter Loscocco (National Security Agency), Mike Hibler, David Andersen, and Jay Lepreau (University of Utah). (See Resources).
Flask both labels and controls file descriptions. The SID of the creating process is present in the label of an open file, which is different than the label of the file itself. Even if a process has permission to access a file, the open file description it may inherit may be non-representational of the current state of the file itself. Such a process would have to use the file's label (and the associated permissions) to access the file. Flask also controls each object that is affected by a file or directory service. In addition to checking the access to a file's parent directory, there are permissions relating to the individual file itself for various operations.
Sockets are used as communication proxies in Flask, and have the default name of the creating process for accountability. The security policy can distinguish between clients and servers for streaming socket connections via permissions (here, they are connectto and acceptfrom). It can also restrict the use of port numbers and pathnames to specific processes.
Messages are associated with the sending socket label as well as a differing message label. By default, this is also the sending socket label. SE Linux currently can't send these message labels across a network.
Flask blurs the type/domain distinction that is traditional in TE security schemes. In Flask, a domain is also a type, but one that is associated with a process. The same type can be associated with a process and an object at the same time. Each process has a domain associated with it, and each object is linked to a type, which might or might not also be a domain.
A security policy configuration defines domains for Type Enforcement as well as types. The configuration will specify allowable access to types by domains as well as the domain interactions. It can also specify automatic transitions between domains when certain specific types are executed. This means that specific processes can be put into their own domains automatically. It seems that automatic domain transitions are primarily used to put system daemons into their own domains during system initialization and to change privileges upon the execution of a particular program. An example of this is adding permissions for a trusted program such as newrole in order to change roles. Removing permissions for a potentially dangerous program such as Netscape could also be done to confine the damage that might be caused by a compromised Web browser.
Roles are also defined in the configuration. Each process has a role associated with it: system processes run in system_r role, while users can either be user_r or sysadim_r. The configuration also enumerates the domains that can be entered by a role. Let's say a user executes the program "foobar." By executing it, the user transitions to the user_foobar_t domain. This domain may contain only a subset of the permissions available in the user_t domain associated with that user's initial login.
Security policy configuration goals include controlling raw access to data, protecting the integrity of the kernel and the system software, protecting a privileged process from executing malicious code, and confining any damage done by a privileged process flaw. Another important goal is to protect the administrator role (and domain) from entry without authentication. This is done in SE Linux by requiring that the "login" program, which has an associated authorization process, handle transitions to the administrator role and domain -- which one can only hope actually works.
The actual configuration process is handled through macros. The m4 macro processor expands these macros.
As an example, this code listing shows how SE Linux defines the rlogin_t domain rules using the macro language.
That's it. Whatever is not expressly permitted by an allow is forbidden. No gray areas. Very totalitarian about it. Which, if you think about it, is just what you want a security system to be.
However, remember that there is a set of rules in policy/domains/every.te that applies to every domain in addition to the domain-specific rules. It's also possible to refrain from using such "global" rules in order to provide complete least privilege, and add only those rules that are necessary to each individual domain.
In Part 2 of this series, we'll look at some more raw SE Linux code. We'll dissect how the security_av is computed, as well as how some of the other SE Linux security features are invoked. If you've gotten this far, Part 2 is your payoff.
- By incorporating a commercial product called NetTop, the NSA will reportedly replace several physically separated computers.
- See Stephen Smalley's paper Flask: Flux Advanced Security Kernel, the source for Figures 1-4 in this article.
- Get the National Security Agency's perspective on Security-enhanced Linux.
- The documentation for SE Linux includes details of the design and implementation of the kernel security mechanisms, as well as the security policy configuration.
- Download the source code from the NSA site.
Larry Loeb has been an editor of or written for many of the "dead tree" computer magazines of the last century. Among other things, he has published a book on SET, the protocol developed by Visa and MasterCard for secure electronic transactions. He can be contacted at larryloeb@prodigy.net, and will respond, in most cases.
Table of contents
Next steps from IBM
WebSphere Portal can help your small and midsize business achieve better website security, along with faster time to value with easily deployable and customizable example Web sites.
- Try: Download a free trial version of IBM WebSphere Portal Express V6.1, which offers collaboration, document management, and secure Web content management.
- Article: This article provides an overview of the WebSphere Portal security architecture, including internet security, and secure connections between clients.
- Tutorial: This tutorial take you through the steps to develop and test your first portlet WebSphere Portal Test Environment.
- Demo: These demos show Web 2.0 features available today within WebSphere Portal, as well as several features planned for the future.
- Buy: IBM WebSphere Portal Express
