Security Enhanced (SE) Linux

So you thought you had a pretty secure system, huh? Well, you haven't seen anything until you've checked out the NSA's "Security Enhanced" version of Linux.

Security Art

The National Security Agency (NSA) and computing go way back. The agency was founded in 1952 with the dual mission of protecting U.S. information systems and producing foreign intelligence information. Since its inception, the NSA has had the unenviable job of producing security standards that will keep all communications of the federal government and military secure.

Given that the NSA has been one of the largest consumers of information technology on the planet, their interest in and use of Linux did not come as a surprise to anyone. However, when the development of an NSA-flavored version of Linux, known as “Security Enhanced” (SE) Linux, was announced, it was something of a surprise. Some were nervous, as the NSA and hackers have come to blows over encryption in the past. However, after public examination of SE Linux, it became clear that the NSA had done some pretty terrific work with the Linux kernel.

What Is SE Linux?

Security Enhanced Linux has the simple goal of managing access to system resources through strong typing and domain control. In English, that means SE Linux (as currently architected) runs a security server inside the kernel that determines what system resources a process has access to. Using a flexible policy definition system, SE Linux acts as an arbiter for all objects the kernel makes available to processes, including files, other processes (for process control security), and memory.

SE Linux, which is available as a tarball from the SE Linux Web site (see the Resources sidebar, pg 26), is designed to be installed on top of an existing distribution. It is not a distribution in and of itself. Originally designed for use with the 2.2.12 kernel, SE Linux as downloaded is configured to work with Red Hat 6.1. Using it with other distributions will lead to some policy errors. While we did not attempt to test SE Linux under Red Hat 7.0 or 7.1, according to Pete Loscocco of the NSA (the project’s leader), it works, but he doesn’t recommend using it with those distros.

Correctly configured, a system based upon an SE Linux kernel shouldn’t experience issues with users overstepping their bounds. Those familiar with computer security can tell you that gaining control of a user account is the first step towards gaining control of the entire system. With an SE Linux kernel, your system can restrict users into domains with very specific access rights and permissions.

SE Linux’s security policy is very configurable, allowing the system administrator, or more properly, the security policy administrator, to create domains with very specific abilities. For example, SE Linux can be configured so that it is impossible for users coming in over the network to switch domains (thus, they can be restricted from entering the system administrator domain).

SE Linux also comes configured with restrictions on Netscape; instead of inheriting the abilities of the user that executes Netscape, the process inherits a subset of that user’s abilities that allows it to run, but in it’s own, very well defined sandbox. The security policies SE Linux makes available can be customized to suit any site’s needs.

Many of you may remember that one of the original promises of Java was that it would allow applications to run in a “secure sandbox.” In reality, the proposition that a user-space application can control access to system resources is just not tenable. Security must come from the operating system itself. A system administrator should be able to define restricted environments and assign those environments to the programs on his system. In a system equipped with SE Linux, you can create very detailed, careful environments where a program can do exactly what it is assigned to do and nothing more.

However, SE Linux can do much more than that. For one thing, it acts to protect the kernel from malicious programs being run in the root context during initialization of the system and the module loading process. For another, it protects configuration files from being tampered with, making it very difficult to change the access controls on the system. And, as we’ve said, by restricting programs to their respective domains, SE Linux acts to contain the damage any given program can do. Our friends at the NSA realize that sometimes security means mitigating the damage a program can do.

SE Linux is based on a security architecture called FLASK and was developed by the NSA, the University of Utah, and the Secure Computing Corporation. In essence, it is the FLASK architecture that allows for the creation of these domains. The NSA decided to create a Linux kernel that featured FLASK in order to, “transfer the technology to a large developer and user community.” The NSA chose Linux because of its open source nature. They felt it would facilitate the use of secure computing within the government.

The FLASK security architecture can be understood pretty easily. It derives its power from the simple concept that every resource which the system can offer a program is an object. There are more than 140 different permissions defined in 28 object classes. This leads to the following set of rules:

  • Objects have associated types;
  • Processes have associated domains;
  • Permissions are defined for all object/resource requests and assigned between domains and types.

Then there is the notion of “roles.” Roles specify things such as:

  • What types of objects can enter which domains;
  • Which domains can access what types of objects;
  • Which domains can access which other domains and under what set of circumstances.

Every process has an associated role. Roles define which domains and types a process has access to. For instance, the login process runs inside the system_r role and has the ability (upon user login) to pass on a shell that runs within the more limited user_r role or, in the event of a system administrator login, a shell that runs within the system_r role.

The user (running in the user_r role) might decide to run Netscape, which the system would allow, with the caveat that Netscape would run under the user_ netscape_r role, limiting the amount of damage that a malicious Web page might do. (Alas, it still won’t do anything about the <blink> tag…)

Programs that Are Modified to Work with SE Linux

SE Linux ships with a number of programs modified to work with it. For example, earlier in this article we made use of the ps and ls commands, both using the –context parameter. This parameter is obviously not part of standard ls or ps. Other programs that have been modified to work with SE Linux include, but aren’t limited to:

  • The file utilities ls, ln, dd, df, pwd, cp, chmod, chown, chgrp, and more…
  • find
  • logrotate
  • The netkit, including rcp, rsh, rexec, rexecd, and more…
  • Tools to work the proc filesystem, such as ps, free, sysctl, top, vmstat, uptime, and more…
  • init, login, cron, tar, and wu-ftpd
  • Tools to work with the password databases nis and radius

Additionally, the newrole utility is included and allows users to switch roles in the same way that we currently switch users using su.

For a complete collection of modified commands, check out the contents of the slinux/ utils directory.

What Isn’t SE Linux?


Peter Loscocco, the NSA program lead of SELinux, noted that: “There is always going to be a performance hit for security. We have to accept that. Nothing is for free. With that said however, we have been running SE Linux for a while, and there is no perceivable impact on users.”

At the Linux Kernel summit held in San Jose, CA in March of 2001, Loscocco noted that the impact of SE Linux on OS performance was most pronounced when programs utilized pipes to communicate with other processes. This causes a security check on both sides of the pipe. That said, the impact was minimal on a user. So while tests have not yet been performed using applications such as Apache and Postgres, the expectation is that they will definitely run slower.

Even so, as Loscocco has noted, on a macro-level, users have not experienced perceivable delays.


The most important thing to realize about SE Linux is that it was never intended to be more than a research system. It is complete, but it has not been optimized for speed. One thing to look for on the horizon is fruition of the efforts of the Linux Security Module (LSM) group. Once the LSM interface to the kernel is complete, SE Linux will work as a kernel module with that interface and be easier to apply against a stock kernel. Note that while SE Linux isn’t done, it’s certainly useful and working right now.


SE Linux isn’t a cryptographic infrastructure for Linux. While this may be obvious, it’s worth pointing out that SE Linux is not a tool like PGP or DES and doesn’t pretend to be.


Finally, SE Linux isn’t easy to configure. It’s complicated to implement. We can only hope that a user-friendly configuration tool is on someone’s whiteboard somewhere. Barring that, SE Linux simply won’t see adoption in some places that could otherwise make particularly good use of it.


As mentioned earlier, SE Linux was originally designed to run on top of a stock Red Hat 6.1 distribution and has some problems under other distributions. Under any distribution you attempt to use it with, you’ll need to install that distro’s development tools so that you can build the kernel and supplied SE Linux tools.

To obtain the SE Linux software itself, it’s probably easiest to download the large (31 MB) package from the SE Linux Web site; this will ensure a properly patched kernel with all the docs and support files you’ll need. If you are feeling more adventurous, you can download a more modern kernel separately. There are patches for 2.2.19 and 2.4.2 available.

If you have a piece of hardware that you want to support which is supported in 2.4.2 or 2.2.19 and not 2.2.12, or if you plan on putting SE Linux into production (something which is not recommended by either the NSA or Linux Magazine), then you’re probably looking to have the most up-to-date kernel available. However, for the purposes of this article, it’s best to just download the big file and work from that for now.

Included in the package is an INSTALL file under the slinux/doc directory. This file details exactly the steps you need to follow to install SE Linux on your machine. The short form of the installation is simple.

Before you start, you must do the following preparation work:

  • Download the code as noted above and untar it.
  • Create jdoe and jadmin users. It will save you some time configuring things later. The SE Linux system comes configured for root, jdoe, and jadmin. jadmin is a user with system administrator privileges (role sysadm_r). jdoe is a user with user privileges (role user_r). You can add users to the system pretty easily, just look at the docs or grep for jdoe in the policy and doc/context_examples directory; you’ll see what needs to be done.

When you untar the slinux.tgz file, you’ll be presented with a number of directories: doc, include, kernel, libsecure, policy, syscalls, tools, and utils. Make sure you have enough space to complete the build process — you’ll need an additional 40 MB.

Now all you need to do is follow these simple steps:

Step 1:

To begin, build the provided kernel through the ./tools/build-kernel script. This will take you into make menuconfig and will handle the details of building the kernel modules.

Step 2:

It is time to build the special tools (ls, ps, dd, and the like) to work with the FLASK-enabled Linux system. Type in ./tools/build-apps from the slinux directory.

Step 3:

After those tools have successfully been built (check the logs in the slinux directory, where you should be), install them using the install-kernel and install-apps scripts in the tools directory.

The install-kernel script will copy the kernel to /boot and run lilo. That said, it’s wise to double-check the lilo work it does and make sure you still have access to your older kernel. It won’t overwrite it, but you want to make sure that lilo is configured correctly.

Step 4:

Copy the context files from doc/ context_examples into the /etc/ security directory.

Step 5:

Reboot your system. Make sure you are able to load a FLASK-enabled kernel; a uname should give you something not unlike:

Linux ws2 2.2.12-FLASK #1
Fri May 18 12:55:45 UTC
2001 i686 unknown

Step 6:

Enter into the policy directory. This stuff needs tweaking for your system but can be left alone if you created the users as noted above. The quick and dirty of it is to run make relabel as root and then make install. This will create the policy files for your system and layout the SID (Security Identifier) files for the inodes.

Step 7:

Reboot. Since we didn’t tweak anything, you’ll see a bunch of messages from the security server. That’s okay for now. If you were to put this system into production, you would want to fine-tune your policies anyhow, and then you wouldn’t see those messages anymore.

SE Linux is now installed. Have fun! You must change your path to include /usr/flask/bin and /usr/flask/ sbin, otherwise the specialized FLASK-enabled commands will not work. You should be able to explore the system now.

Exploring SE Linux

It is educational to examine a process table of a system running a FLASK-enabled kernel, as illustrated in Figure One.

Figure One: Edited Output of ps -afwx –context

PID CONTEXT                COMMAND
1 system_u:system_r:init_t init
2 system_u:system_r:kernel_t [kflushd]
76 system_u:system_r:sysadm_t pump -i eth0
174 system_u:system_r:init_t /usr/sbin/atd
177 system_u:system_r:init_t /usr/sbin/cron
180 system_u:system_r:getty_t login — chris
186 chris:user_r:user_t \_ -bash
187 chris:user_r:user_t \_ sh /usr/bin/X11/startx
197 chris:user_r:user_t \_ xinit /usr/X11R6/lib/X11/xinit/xinitrc — -auth/home/chris/.Xauthority
198 chris:user_r:user_t \_ X :0 -auth /home/chris/.Xauthority
202 chris:user_r:user_t \_ x-window-manager
225 chris:user_r:user_ \_ /usr/bin/ssh-agent x-window-manager
185 system_u:system_r:getty_t /sbin/getty 38400 tty6
229 chris:user_r:user_t /usr/bin/Eterm
232 chris:user_r:user_t \_ -bash
402 chris:user_r:user_t \_ script holdme
403 chris:user_r:user_t \_ script holdme
404 chris:user_r:user_t \_ bash -i
408 chris:user_r:user_t \_ ps -afwx –context

Note the interaction between types, roles, and user contexts. The init_t typed init program is running under a system role which launched the pump, atd, cron, and login programs (among others). Also note how some are running under the init_t type and others picked up a new type, like login from getty and bash from login. When login spawned a shell for chris, it used the user_r role for chris.

Figure Two illustrates several edited entries retrieved from running ls –context.

Figure Two: Edited Entries Retrieved from Running <ls –context>

ls –context `which login`

-rwsr-xr-x root root system_u:object_r:bin_t /bin/login

ls –context `which init`

-rwxr-xr-x root root system_u:object_r:init_exec_t init

ls –context /usr/sbin

(many lines deleted)

-rwxr-xr-x root root system_u:object_r:insmod_exec_t insmod
-rwxr-xr-x root root system_u:object_r:sbin_t mkswap
-rwxr-xr-x root root system_u:object_r:portmap_exec_t portmap
-rwxr-xr-x root root system_u:object_r:sbin_t pump
lrwxrwxrwx root root system_u:object_r:rmmod_exec_t rmmod -> insmod
-rwsr-xr-x root mail system_u:object_r:sendmail_exec_t sendmail

ls –context /etc

-rw-r–r– root root system_u:object_r:etc_aliases_t aliases
-rw-r–r– root root system_u:object_r:etc_t fstab
-rwxr-xr-x root root system_u:object_r:etc_t lpd

Looking at the ls output, you’ll see that all of these files are objects, accessible to the system_u domain, and many of the files have different types that are mapped by the security policy server to a variety of special permissions. Note how pump and mkswap are of the same type (the majority of programs in sbin are of the sbin_t type), but special programs like portmap, rmmod, and the rest are covered under their own special types. The idea behind all the different types is that a security policy administrator can create roles that allow for, say, kernel management, but not network management or configuration of some etc files.

Considering the power of this typing system, you could easily create types specifically for an e-mail manager that handled sendmail, aliases, procmail, and other related programs; this would allow the e-mail administrator to administer e-mail without restraint, but also without being able to touch the rest of the system.

The Future of SE Linux

As we mentioned earlier, SE Linux should not be considered ready for production. Peter Loscocco, the project’s leader, has indicated that in the future, SE Linux will interface with the Linux kernel as a module using the LSM interface that is currently under development.

Loscocco and Steve Smalley of Network Associates (NAI) Labs are both active in the LSM project and consider it key to the adoption and further development of SE Linux, as the project would then be able to target the LSM interface and not the changing internal data structures of the kernel. The LSM project came about as a result of conversations at the Linux Kernel Summit regarding the need for a security architecture for the 2.5 Linux kernels.

Loscocco has stated that one of his goals is to see that LSM is crafted appropriately and accepted into the 2.5 kernel. Once that interface is in the OS, adding modules like FLASK will become much easier, as will the development of a more secure operation system. A laudable goal indeed!


SE Linux Home Page: http://www.nsa.gov/selinux/index.html

Linux Security Module Home Page: http://lsm.immunix.org

MP3 of Mr. Loscocco’s Summit Presentation: http://www.osdn.com/conferences/kernel

NAI Labs: http://www.pgp.com/research/nailabs

University of Utah Flux Research Group: http://www.cs.utah.edu/flux

Secure Computing Corporation: http://www.sctc.com

Author’s home page: http://dibona.com

Chris DiBona is the Program Director for the Open Source Development Network. He can be reached through his personal Web site at http://dibona.com.

Comments are closed.