Doug Ross @ Journal

The most secure operating system on the planet?

The most secure operating system on the planet is arguably SELinux (Security-Enhanced Linux), which is now bundled with RedHat's Enterprise Linux. SELinux began as an NSA research project, which added a mandatory access control architecture into the Linux kernel.

Now Novell has added AppArmor to SUSE Linux through its purchase of Immunix. It, too, provides a mandatory access control architecture.

So what is mandatory access control?

Traditional access control systems are called 'discretionary'. That is, a user can accidentally or intentionally provide access to his or her resources to unauthorized users. An example of this is a corporate user who creates a file on a shared drive and then gives everyone on the network the ability to read the file. This would not be wise if, for instance, the file was a salary spreadsheet or contained other sensitive data.

Another example of a discretionary access control system is more pervasive and potentially dangerous. Consider a web server that is compromised remotely by an attacker using a zero-day exploit. The attacker, running as the web server, has all the access rights the server does. The attacker could potentially wreak havoc by reading sensitive files, installing nefarious software, or vandalizing the machine.

Most operating systems we use today -- including Windows and default installations of Linux -- are discretionary access control systems.

Mandatory access controls (MAC) use a system security policy that completely restricts the access to be granted for its users and processes. Let's say I create a file. In a MAC environment, I no longer control who can access the file. A system security policy, defined by an administrator, determines my access rights. And I can't make the rights less restrictive... only more restrictive.

Take the web server example in a MAC system. The web server should only be able to access files under its direct control (say, a configuration file, logs, the document root, virtual directories, etc.). Any other access (say, of the password file) violates policy and therefore throws an alarm.

Okay, so how does MAC work?

MAC needs to be integrated at the kernel level of an operating system. An application simply can't be trusted. Therefore, the OS kernel must support MAC to ensure adherence to security policy.

In the older versions of the Linux kernel, MAC was implemented directly in the kernel code and "bolted on" with conditional compiles. As you could have expected, this got downright ugly from a maintenance perspective.

The version 2.6 rewrite of the Linux Kernel allowed designers to step back and reevaluate how MAC could be integrated into the OS. What they come up with was -- dare I say it -- downright elegant. They invented a loadable module interface called LSM (Linux Security Module), which provides a kernel API for run-time access control mediation.

The kernel now includes LSM "hooks", which make "up-calls" for each access control decision. If no LSMs are loaded, the up-calls come back with a "thumbs up". If LSMs are loaded, however, they can assess the request and come back with a "yes" or "no" answer to the kernel. The kernel can, in turn, allow the access or return an error the requestor, respectively.

The neat thing about the new LSM approach is that SELinux and AppArmor can perform their mediation work as loadable modules... no more kernel patches or conditional compiles are needed.

So why doesn't everyone use MAC?

The issue with actually implementing SELinux is configuration complexity. Trying to describe policies for processes is painful and difficult; the tools to help are rudimentary and somewhat immature. To get a sense of its complexity, the Gentoo SELinux Overview is the online equivalent of Ambien.

AppArmor, however, provides some unique tools to make administration of MAC easier. It includes "learning mode", which lets an application run unconstrained and monitors its behavior. In this mode, access control rules are ignored, but any violations are logged. In addition, process forking is monitored. Thus, AppArmor can build up a complete description of the application's legitimate activities.

Why is AppArmor easier to use?

From a user interface perspective, AppArmor provides the administrator with a profile-building application. This app reads the log and interviews the administrator. Once the interview is complete, the program profile is created. If a profile has already been started, the app can build upon the existing profile by adding incremental knowledge to it.

Profiling is typically performed for applications that access the network (e.g., a web server that could theoretically be compromised through a zero-day buffer overflow exploit). But there's nothing that prevents other programs from similar analysis.

The AppArmor documentation describes a hypothetical kiosk workstation. Each program running on the kiosk could be attacked by users. Therefore, an administrator could profile each of these apps and any attached devices (say, a bar-code scanner) to secure the system from externally sourced compromise.

Sounds neat, but... what's your point?

As MAC systems become more prevalent, expect financial institutions, communications companies, and other large organizations to run their publicly facing bastion servers on secure operating systems. It won't be acceptable -- from either a security or a liability viewpoint -- to accept the risks associated with discretionary systems.

In other words, at some point in the not-so-distant future, MAC systems will be required. Whether the requirement is explicit (e.g., via regulatory dictate like Sarbanes-Oxley) or implicit (the threat of lawsuit), expect MAC to go mainstream.