Paranoid Penguin - An Introduction to Novell AppArmor

In my article “Security Features in SUSE 10” (LJ, April 2006), I described Novell AppArmor, a partial implementation of mandatory access controls (MACs) that is now part of SUSE Linux. Since that writing, Novell has released the source code of AppArmor under the GPL. It's entirely possible that in the near future, AppArmor will be ported to other Linux distributions that support Linux security modules.

This is great news. In my opinion, AppArmor represents a major step forward in making MAC technology a feasible option for system administrators who want strong security controls but don't have the time or patience to configure and maintain a complicated “trusted OS” such as SELinux.

This month, I introduce the concept of mandatory access controls, describe the difference between Novell AppArmor and NSA SELinux, and show you how to get started with AppArmor on your SUSE systems.

The easiest way to describe mandatory access controls is to contrast it with discretionary access controls (DACs). Most general-purpose operating systems use a DAC security model, in which the owner of a given system resource (file, directory and so forth) can set whatever access permissions on that resource they like. Stringent security controls, in general, are optional.

By contrast, a computer with MAC has a global security policy to which all users of the system are subject. A user who creates a file on a MAC system generally may not set access controls on that file that are weaker than the controls dictated by the system security policy.

Most DAC implementations have several major problems, emphatically including both Windows and Linux (except SELinux). First and most obvious is that, as with any scenario involving human beings, making any type of work optional all but ensures that work won't get done very often. It takes work to use careful security settings consistently, even in a DAC system.

Another problem with DAC is that DAC-based OSes tend to have a “winner take all” security model, in which the only way to get anything important done on the system is through the superuser account (root in Linux/UNIX, Administrator in Windows). Wholly compromising a system using such a security model is generally a simple matter of hijacking some process on that system that runs with root/Administrator privileges.

On a MAC-based system, however, the only thing the superuser account is used for is maintaining the global security policy. Day-to-day system administration is performed using accounts that lack the authority to change the global security policy. As a result, it's impossible to compromise the entire system by attacking any one process. (Attacks on the superuser account are still possible, however; for example, by booting the system into single-user mode from its physical console.)

If mandatory access controls are superior to DACs, why aren't they ubiquitous? Unfortunately, although MAC schemes have been available on various platforms over the years, they traditionally have been much more complicated to configure and maintain than DAC-based operating systems. Creating an effective global security policy requires detailed knowledge of the precise (intended) behavior of every application on the system. Furthermore, the more restrictive the security controls are on a given system, the less convenient that system becomes for its users to use.

AppArmor isn't the first mandatory access control scheme for Linux, nor is it the most comprehensive. It shares DNA, so to speak, with SELinux, a project of the US National Security Agency. (The shared DNA is the Linux Security Modules, which provide kernel support for MAC.)

SELinux is a bundle of kernel modules and user-space configuration tools that implement three different types of MAC:

In SELinux, all three types of access controls (TE, RBAC and MLS) are applied across the entire operating system. This requires major system applications to be SELinux-aware wherever possible, and it also requires extensive setup by a knowledgeable system administrator (that is, one who has carefully researched SELinux). On the one hand, SELinux is truly comprehensive. On the other hand, configuring it is a fairly major undertaking.

Novell AppArmor has a more modest objective: to restrict the behavior of selected applications in a very granular but targeted way. In focusing on applications (at the expense of roles and data classification), AppArmor is built on the assumption that the single biggest attack vector on most systems is application vulnerabilities. If the application's behavior is restricted, the behavior of any attacker who succeeds in exploiting some vulnerability in that application also will be restricted.

For example, suppose you're running a Web application that runs as user nobody and uses user input to update a local text file. On a typical system, if an attacker compromised that Web application, for example, by sending unexpected input, the attacker might succeed in gaining a remote shell with the privileges of nobody. If that Web application were protected by AppArmor, however, all the attacker would be able to do is alter that single text file. It wouldn't be possible for the attacker to spawn a remote shell (an unexpected action) or to read or write any other files.

Comprehensive? By no means. For non-AppArmor-protected applications, the usual (limited) user/group permissions still apply, no controls regarding data classification are provided, and normally, only a subset of applications on the system have AppArmor profiles.

For the most part, root is still root, and if you use root access in a sloppy or risky fashion, AppArmor generally won't protect you from yourself. But, if an AppArmor-protected application runs as root, and becomes compromised somehow, that application's access will be contained, root privileges notwithstanding, because those privileges are trumped by the AppArmor policy (which is enforced at the kernel level, courtesy of Linux security modules).

AppArmor is therefore only a partial implementation of mandatory access controls. But on networked systems, application security is arguably the single-most important area of concern, and that's what AppArmor zeros in on. What's more, AppArmor provides application security through an easy-to-use graphical user interface that is fully integrated with YaST. (GUI tools are now being developed for SELinux as well, but just how easy to use these are is open to debate.)

Still, I'm stopping well short of suggesting AppArmor is interchangeable with SELinux. If, for example, you run Linux in a multiuser environment (in which users have shell or database accounts) involving highly sensitive data, there really is no substitute for the comprehensive layers of access controls in SELinux.