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:
Type enforcement (TE): associates a security “label” with every system object.
Role-based access controls (RBACs): define particular actions and contexts in which system objects may be involved.
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.
|Designing Electronics with Linux||May 22, 2013|
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
- Designing Electronics with Linux
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Dynamic DNS—an Object Lesson in Problem Solving
- Using Salt Stack and Vagrant for Drupal Development
- New Products
- Build a Skype Server for Your Home Phone System
- Validate an E-Mail Address with PHP, the Right Way
- Why Python?
- A Topic for Discussion - Open Source Feature-Richness?
- Tech Tip: Really Simple HTTP Server with Python
3 hours 30 min ago
- Reply to comment | Linux Journal
3 hours 38 min ago
- Understanding the Linux Kernel
5 hours 52 min ago
8 hours 22 min ago
- Kernel Problem
18 hours 25 min ago
- BASH script to log IPs on public web server
22 hours 52 min ago
1 day 2 hours ago
- Reply to comment | Linux Journal
1 day 3 hours ago
- All the articles you talked
1 day 5 hours ago
- All the articles you talked
1 day 5 hours ago
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?