Paranoid Penguin - An Introduction to Novell AppArmor

Who says “easy-to-use mandatory access controls” is a contradiction in terms?

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.

Introduction to Mandatory Access Controls

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 vs. SELinux

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:

  1. Type enforcement (TE): associates a security “label” with every system object.

  2. Role-based access controls (RBACs): define particular actions and contexts in which system objects may be involved.

  3. Multi-level security (MLS): defines access controls against objects based on data classification (sensitivity).

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.

______________________

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Great Article

Linux User's picture

Thanks for the great information on apparmor.

help me now

help me now's picture

I've posted the series over on my education blog, so commenting is open.

White Paper
Linux Management with Red Hat Satellite: Measuring Business Impact and ROI

Linux has become a key foundation for supporting today's rapidly growing IT environments. Linux is being used to deploy business applications and databases, trading on its reputation as a low-cost operating environment. For many IT organizations, Linux is a mainstay for deploying Web servers and has evolved from handling basic file, print, and utility workloads to running mission-critical applications and databases, physically, virtually, and in the cloud. As Linux grows in importance in terms of value to the business, managing Linux environments to high standards of service quality — availability, security, and performance — becomes an essential requirement for business success.

Learn More

Sponsored by Red Hat

White Paper
Private PaaS for the Agile Enterprise

If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.

Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.

Learn More

Sponsored by ActiveState