Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

An Overview of Security Enhanced Linux

By Jetifi in Technology
Sun Jun 17, 2001 at 04:51:52 AM EST
Tags: Security (all tags)

Security Enhanced Linux (or 'SE Linux') was released by the National Security Agency in 2001 under the GPL. It consists of a patched kernel plus utilities, and was written with the goal of incorporating a flexible mandatory access control architecture in to the Linux 2.4.x kernel.

This article is intended to provide an explanation of the technologies used, and an overview of the capabilities of SE Linux.

Sponsor: rusty
This space intentionally left blank
...because it's waiting for your ad. So why are you still reading this? Come on, get going. Read the story, and then get an ad. Alright stop it. I'm not going to say anything else. Now you're just being silly. STOP LOOKING AT ME! I'm done!
comments (24)
active | buy ad


Most modern operating systems use a 'discretionary access control' (DAC) security model. This means that they restrict access to objects based on their classification. This type of control is discretionary in the sense that a subject with a certain set of access permissions is capable of passing those permissions on to another subject. For example, any program you run while logged on as a certain user has the same access rights as you do. Rights are set by another user (for example, 'root' or 'administrator').

Any particular permission (read, write, execute, etc.) can be thought of as a two-dimensional matrix with users on one axis and objects on another. In essence, DAC systems check the validity of credentials presented to them against stored information.

Another security model is mandatory access control, or MAC. This controls access in an different manner. Whereas DAC security models are authentication-based, MAC systems rely on authorization, not only of the user but also of each object loaded by the system.

A MAC system controls objects individually, and make decisions on the rights and/or permissions of objects based on a security policy, which can define what rights the object should be accorded based on different variables.

An example of how discretionary versus mandatory access control styles could affect the operation of a computer would be a cgi script. If the script allows an external entity to insert and execute malicious code on a computer system under a DAC system, the malicious code now has the same access rights as the code that executed it - the cgi script. This is one of the reasons why buffer overflows work.

A MAC system can restrict the rights of a certain process to only the resources needed for normal operation. A cgi script may create a process (or it may be forbidden), but that process might not have the same set of permissions as the process that created it.

Security Policies

The MAC system which is used by SE Linux is called Flask. Flask originally grew out of a collaboration between the Information Assurance Research Office of the NSA and the Secure Computing Corporation (SCC) to develop a strong, flexible MAC system based on Type Enforcement (explained below). Two prototypes, DTMach and DTOS, were developed, using the Mach microkernel as a starting point.

The system was then ported over to a research operating system called Fluke, which is/was maintained by the Flux research group of the University of Utah. During the porting, several advanced features were added, and the final result is the Flask MAC architecture. This is what has been ported to Linux.

One of the main features of Flask is the separation of policy definition and policy enforcement. All security policy related logic is done by the 'security server' - this was external to the Fluke kernel, but is implemented in Linux as a kernel sub-system.

The security policy configuration is defined in a text file which is compiled by a separate program, normally at boot time, and loaded in to memory. Only the security server can make policy decisions on the permissions of an object.

The security policy enforcement is done by components called object managers, which receives requests from client objects, submits queries to the security server, and enforces the resulting decisions. Flask specifies the interface between the security server and other subsystems.

The SE Linux implementation of the security server uses a combination of type enforcement (TE) and Role Based Access Control (RBAC). It can also use Multi-Level Security (MLS) which is mainly used in military environments for dealing with different data classifications (i.e. Secret, Top Secret, Compartmentalized, etc.) and less so elsewhere. It is not discussed here.

  • Type enforcement

Type enforcement makes security decisions based on what kind of object (in the case of Flask, the object managers' client) is requesting the permissions. For example, object types could include a regular file, a directory, a process, a socket, or further sub-divisions of these rather broad categorizations. Type enforcement is an object labelling system, that, combined with access mapping (from the domain of the object requesting permission, and to the type of the object requested), returns a decision which defines the permissible actions of the object.

An example of how type enforcement works would be if you gained root access through a buffer overflow in a network server daemon in it's own domain, where files accessible to that domain have one of two possible types: normal files with which you have only read and execute permissions, and incoming files on which you have only write. As you have root access, all discretionary controls are bypassed, but the fact that you are running in a domain with no write access to normal files prevents you from writing anything to, for example, /etc/passwd.

This is a simplified example, as in a MAC system which used type enforcement you would have many more domains and types. The type enforcement used in Flask is a generalised version of domain and type enforcement (DTE), which has been implemented in the Linux Kernel.

  • Role Based Access Control

Role Based Access Control (RBAC) assigns permissions to objects in a computer system based on the role they play within that system. In practice this means that a process would have it's permissions based on it's parent process, the user logged on at the time, and any number of other variables.

A real-world example of RBAC would be a hospital system, where the role of nurse would include preparations for surgery, and applying medication. But surgery itself is exclusive to the role of the surgeon. The role of a researcher collecting tissue samples would have a more limited set of rights.

RBAC in Flask can depend on any number of variables, as the role an object plays in a given system can be subjected to any amount of analysis.

Policy Enforcement

Flask combines type enforcement and RBAC when making decisions. It can also make use of MLS. To start with, each object is assigned a security identifier (SID) by the object manager charged with enforcing the decisions of the security server. SIDs in SE Linux are 32-bit numbers, with a data structure private to the security server. They represent the context in which the object was created, and are used by the security server to make decisions about that object's permissions.

A normal SID consists of user ID, role (as discussed above), type, and maybe an MLS range. Roles are normally relevant only to processes, while sockets and files have a generic role unless otherwise defined. The security server only assigns SIDs to legal combinations of user, role, type etc. according to the security policy. As in the example with the cgi interface above, the security server might deny a SID to a process created by a given object, in this case the piece of cgi may have been compromised.

There are three main types of objects which can request SIDs from the security server in SE Linux - processes, file systems, and sockets.

  1. Processes

    Under SE Linux each process has a SID, which governs the access permissions of the process. The SID of a process can be changed, which allows processes the ability to transition across security domains, although the capability must be explicitly allowed.

    A new process is usually assigned the type of it's parent. The role of a process is normally a combination of the process that spawned it, the current user ID, and it's intended type. Also controlled is the ability of processes to configure network interfaces and routing tables.

  2. File systems

    The file system object manager controls ten object types, of which the four main ones are mountable file systems, directories, files, and file description objects. At present SE Linux only supports the ext2 file system, although more are planned.

    SIDs are different in a file system context in that file objects are assigned persistent SIDs (PSID)s - unlike normal SIDs, they don't change over boots. Each object's PSID is stored in an unused field of the inode.

    For file creation, the PSID is created from the process, parent directory, and the kind of file. The security server may also use other external information to make decisions.

  3. Sockets

    Flask controls the use of sockets at the socket, transport and network layer. This means that it is possible to forbid a user (or other object) access to a raw IP socket (which allows the possibility of forging packets), while allowing access to UDP or TCP sockets. Setting port-specific permissions is also possible.

    The process-socket interaction and socket communication privileges can also be controlled. In addition, it is possible to send and receive messages through network interfaces to other nodes in the network

    On most tasks the overhead SE Linux imposes due to security checks and policy decisions is on the order of 1 to 2 percent thanks to various caching mechanisms. However, in networking, the overhead is often as high as 10 percent. This has an obvious impact on the potential uses of SE Linux in network-oriented deployments.

How processes, file system objects and sockets communicate with each other is defined by the security policy. This is written in the form of a large human-readable text file which has it's own (fairly complex) syntax. In particular, the security policy governs how different types and roles may interact, along with any specific rules.

SE Linux has a kernel compile-time configuration option that switches the resulting kernel in to 'audit' mode: instead of enforcing security decisions, it simply logs all decisions taken, and any violations of the security policy that occur. This is used when setting up the system initially, to gauge which objects need which permissions, and to help in setting up a comprehensive security policy. In active mode, the decisions of the security server are actively enforced.

At present SE Linux provides binary compatibility with existing applications, and source compatibility with kernel modules. The patch also adds some security-related system calls. SE Linux only supports the ext2 file system - others may be mounted, but permissions cannot be set at a resolution lower than the file-system classification itself. The current implementation of SE Linux is x86-specific.

Why it exists

SE Linux was released by the 'Information Assurance Research' office of the NSA. This department belongs to the non-scary half of the NSA that is responsible for securing computer-related national infrastructure, protecting US companies (Such as Boeing, Lockheed Martin, other defence contractors, hi-tech companies, etc. ) from industrial espionage, and the like.

Public research in this area stems partly from an increased interest in low-cost and secure systems using MAC architectures throughout the Department of Defence. Additional factors spurring research include the ever-increasing expense of the 'air gap' solution to compartmentalisation of classified data, and some unease about increased reliance on operating systems such as Trusted Solaris, AIX, or IRIX.


The NSA have published a paper entitled 'The inevitability of failure', which explains the philosophy behind Flask and SE Linux. A detailed overview of the Flask architecture was presented at USENIX '99. Also a description of the Flask-Linux integration. The National Computer Security Center has published a good overview of discretionary access control. A NIST bulletin gives a good introduction to role-based access control. NIST also has a good RBAC resources page. The Current SELinux documentation as one big tgz file. A brief overview of different security methodologies. Discretionary versus mandatory access control in a nutshell (in the context of securing Apache). Linux-NSA collaboration - fairly old NewsForge article. A compressed postscript file which (among other things) contains the detailed Flask specification - this may be outdated. IBM has a two-part feature, with a detailed overview and code samples.


Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure


Related Links
o Security Enhanced Linux
o National Security Agency
o the GPL
o Secure Computing Corporation
o Fluke
o Flux
o University of Utah
o Flask MAC architecture
o domain and type enforcement
o The inevitability of failure
o Flask architecture
o Flask-Linu x integration
o discretion ary access control
o introducti on to role-based access control
o RBAC resources page
o Current SELinux documentation
o different security methodologies
o Discretion ary versus mandatory access control
o Linux-NSA collaboration
o detailed Flask specification
o detailed overview
o code samples.
o Also by Jetifi

Display: Sort:
An Overview of Security Enhanced Linux | 15 comments (11 topical, 4 editorial, 0 hidden)
For us lesser mortals (3.50 / 8) (#5)
by 42 on Sun Jun 17, 2001 at 01:15:38 PM EST

I must say that your article does an excellent job of explaining what SE Linux is and the theory behind it. However, this is a work of reference, still : it doesnt make this accessible to lesser mortals like me. For example, if I were working on solving a security problem in a protocol, and I had the idea that SSL / TLS could help me, I would look up the RFC for SSL / TLS. But on the other hand, if you just thrust the RFC into the hand of Joe Intelligent (who hadnt been looking for any solution to a problem) , he / she would be inclined to say "This is nice, but what do I need it for?".

Admittedly, more security is always a good thing. But if I am not working in a top-secret environment (or an environment where all users except root are at the same classification) , yet work within a firewall, I am not sure why I would need to migrate from a DAC model to a MAC security model. Do I need to? If I had to choose between an RBAC model and a MAC model, what would I need to consider to make a choice? It seems to me that whatever can be accomplished within an RBAC model can also be accomplished via the MAC model and vice-versa.

Again, as a reference doc, your article is good. If that was your intention, kudos to you. However, this wasnt what I needed. To me, an article telling me how I could use these new capabilities (say integrating these models with a database authorization scheme or a web server authorization scheme) would have been invaluable.

I think it is a statement .. (3.50 / 4) (#6)
by Highlander on Sun Jun 17, 2001 at 04:45:50 PM EST

For Linux development, the existance of this security model mainly puts into question the basically single layer of security, the distinction between root and non-root.

Putting things into the kernel makes them go faster, but also gives lots of rights to the adde d code - the file system permissions do not apply to the kernel code.

Usually, when a Linux server has been compromised, the advice by experts is to wipe out the server.

However, one argument against having a lot of granularity in the security systems is that it is very hard to manage a convoluted security system.

Moderation in moderation is a good thing.
[ Parent ]

Last point is a good one (3.50 / 4) (#11)
by Alhazred on Mon Jun 18, 2001 at 01:05:04 PM EST

Its a lot like the differences between Apache 1.2.x and 1.3.x. In the "good old" 1.2.x days it was dirt simple to set up virtual hosting. 1.3.x "complexified" that aspect of configuration considerably. Granted that ISP's drove that decision based on their needs, but a lot of us are still annoyed by the added burden of building more complex configurations just to do what we always did before.

It seems to me that over time every software system expands and becomes more complex in an attempt to accomodate every conceivable user. No doubt Linux is following the same path. What we will obviously need is a good tool that can take a fairly simple description of a desired security architecture, and translate that into a set of policies. I certainly don't want to be the one trying to figure out how to set this monster up!
That is not dead which may eternal lie And with strange aeons death itself may die.
[ Parent ]
Don't worry (4.00 / 4) (#12)
by John Milton on Mon Jun 18, 2001 at 04:06:29 PM EST

There are still going to be distros for you. All of them aren't going to change. I can see some advantages to some of these features. The case of script kiddies using buffer overflow is a good one. This would be very helpful on a server. It just needs a simple setup.

"When we consider that woman are treated as property, it is degrading to women that we should Treat our children as property to be disposed of as we see fit." -Elizabeth Cady Stanton

[ Parent ]
I am worried... (3.25 / 4) (#14)
by Alhazred on Tue Jun 19, 2001 at 01:14:23 PM EST

Not about the fact that there "won't be a distro for me", but about the fact that I will NEED the kind of security these systems are implementing and that it will be ugly and complex and a pain in the ass to admin.

Now, you will say "it will be simple" but look at the horrible crappy state of Linux admin tools. We have Red Hat with Linuxconf, half the rest of the world with Webmin, plus YAST, plus whatever Debian uses, plus Corel and Caldera both have their own flavors of tools, and Mandrake has some weird cobbled together hodgepodge of all of them. Then there are tools specific to various subsystems, like Comanche, Samba's thingy (sorry, name escapes me), etc etc ad nauseum.

All of these tools are klunky at best. Obviously there are about 500,000 too many different tools, none of which has had enough effort put into it to make it really work smoothly. Personally I do all my Linux admin by hand on the command line simply because I have had FAR too many experiences of one or another of these tools porking my system completely.

Linux BADLY needs a standardized API for installation and configuration. Without that, all these wonderful extra new features are just minefields we all have to suffer walking through.
That is not dead which may eternal lie And with strange aeons death itself may die.
[ Parent ]
Why? It's your taxes! (3.33 / 3) (#10)
by PoisonRain on Mon Jun 18, 2001 at 11:42:10 AM EST

Very briefly this is one of the few areas where the interests of the government agencies and the public come together nicely. Like CESG, the NSA has a vested interest in securing it's nations IT communications, in this day in age that involves securing right down to OS level.

To this end a lot of government time and therefore money is invested in checking, and in some cases improving, Operating Systems to make them more secure. It is not a quick process and the thoroughness used is mind-blowing, so for a rapidly changing OS like Windows it becomes a real problem.

Open source projects like Linux therefore are a real blessing if the public code can be secured, as thereafter the effort involved in testing future releases for security issues should be substantially reduced. For this to work though the public has to pick it up and run with it. The upside to the public is that we get an OS that has been tested to the highest security standards in the land.

[ Parent ]
another MAC/capabilities implementation... (4.33 / 3) (#7)
by dannyboy on Sun Jun 17, 2001 at 09:58:06 PM EST

TrustedBSD is implementing Posix.1e ACLs (access control lists), MAC, capabilities, and lots of other security goodies in the FreeBSD development branch.

A painful transition (4.33 / 3) (#8)
by ryancooley on Mon Jun 18, 2001 at 01:38:11 AM EST

I'm glad to see Trusted OS features are finding their way into Free(tm) OSes (even if I wish they'd used OpenBSD as the base OS) but I have one concern. It's going to be a painful transition from the old method to the new, but a necessary one.

Right now, I have Apache startup as root, then release root privlidges and run as the 'apache' user, a user who only has rights to READ whatever is inside the HTMLDOCS directory. While this may work properly, just imagine how much code is wasted on this in Apache, and how much of a hassle it is. With ACLs, I could just assign Apache the rights to write to port 80, and rights to read from the HTMLDOCS directory. With that, I never need to worry about an Apache remote root exploit. I would only need to worry about exploits in programs that have read or write access in areas (like /etc) where someone could gradually elevate their rights. With that said, properly implimented ACLs will really improve the security of our machines. However, I would feel much happier if the MAC was implimented on top of a much more secure kernel and supporting application, which is why I will wait for TrustedBSD to complete their work, instead of switching to SE Linux right away.

*cough* (3.00 / 3) (#9)
by Jetifi on Mon Jun 18, 2001 at 07:22:57 AM EST

Um, yes.

I missed some bits out, such as how the TrustedBSD folks were (according to the (old) NewsForge article mentioned in the last paragraph) talking with the NSA over the possiblity of integrating some of their code in to the TrustedBSD systems.

In addition, as 42 says, there's not too many talking points here, (which is what the site's about, after all), so in retrospect I'd have added some open-ended questions such as whether or not a 10% decrease in network transaction speed is an acceptable sacrifice, given the increased security, and if MAC systems have a place outside of high-security environments such as the NSA.

I should have also given a mention to the Linux Intrusion Detection System project, which makes it's own security-related modifications to the kernel.

On a related note, I am also a 'lesser mortal' - this is the result of research, not experience :-)

Skeptical layman (3.00 / 3) (#13)
by goosedaemon on Tue Jun 19, 2001 at 11:11:02 AM EST

I have some issues with this concept. One, how does this help if someone gets the root password? Also, it seems to me that this would lend itself to having things in between user and superuser; does that really improve things? And, suppose we had a daemon that does stuff, and someone cracks it or something, then gives the daemon some kind of command; would they not still be able to do things through the daemon, thereby still having the same permissions as it? Finally, unless I'm misunderstanding this, it's hardly revolutionary, as it resembles the idea of sandboxes ... and that idea has been around for a while.

how capabilities help (4.50 / 2) (#15)
by dannyboy on Tue Jun 19, 2001 at 02:03:17 PM EST

Well, to address one of the things you've said, say we have a daemon that does stuff (good thing to do) and you crack it, gaining the ability to execute arbitrary code with all the access of the daemon. With capabilities, the daemon doesn't need as much access. Quite a few network daemons use superuser privileges only to bind to privileged ports; with capabilities you can avoid running the daemon as the superuser and instead just give it the ability to bind to privileged port n. Assuming only capabilities (not even considering MAC and such), you would be able to do things with the daemon's permissions, but the daemon wouldn't have as many permissions to begin with.

Did I make sense? I'm not really awake right now, sorry...

[ Parent ]
An Overview of Security Enhanced Linux | 15 comments (11 topical, 4 editorial, 0 hidden)
Display: Sort:


All trademarks and copyrights on this page are owned by their respective companies. The Rest 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!