Tuesday, September 25, 2012

AppArmor, MAC, and Why You Should Care

The traditional Linux security model is derived from Unix.  This model is known as Discretionary Access Control (DAC).  In this model file access is specified by the owner (or group) permissions of the file.  This is the traditional UGO (user-group-other) model most of us are familiar with on Unix like systems. Essentially, this means "Bob" is free to modify any files he owns.  If he doesn't own the file, then someone else (a different user or the system admin) determines what access (if any) he has by setting the r-w-x bit.  If the file is owned by Bob, he can change the r-w-x bits as he sees fit.  And of course, the root user (superuser) can change the ownership of any file as well as set the rwx bits as he/she sees fit.



While DAC is great for separating user level processes and files from root owned processes and files (and likewise separating users from each other), it does nothing to separate things *within* a particular domain.  That is, what if Bob does not want process A to be able to read or write to the files of process B (both of which are owned by Bob)?  Or worse yet, what if he wants to stop process A from executing another process?  Using DAC he is out of luck.  Even Access Control Lists (ACL's), which are built into Linux, are not really sufficient.  ACL's are simply an extension of the traditional UGO model.

In the old days (70's-80's) it was common to have many users running from the same central mainframe (aka "time sharing").  Each user connected with a client machine and ran everything from the single mainframe OS.  The DAC model was designed back then to solve a problem with such multi-user  systems like Unix.  That is, there needed to be a way to prohibit Alice from reading or modifying Bob's files (and vice versa).  Likewise, the system admin didn't want Alice and Bob messing with system (root owned) files or processes.  DAC does a pretty good job keeping various users separated from each other and from the root filesystem.  The problem is it does nothing to keep files and processes separated *within* a user's domain.

As the 90's came around and more people began using a single machine for a single user, DAC became a bit outdated.  Now, in the 21st century, it is almost unheard of for anyone to "share" a system.  Most everyone uses a single machine for a single user.  After all, computing power is so cheap that it makes sense.  This means DAC today is really only good for separating that one user from root owned files and processes.  Moreover, things are made worse since every user essentially has root access to his own machine, as opposed to the "old days" when only one system admin who was sufficiently knowledgeable had root access.

One Solution

A solution to this problem has long been recognized, but has not been seriously implemented in general purpose OS's until the last few years.  Even now, it is not used widely enough.  That solution is known as Mandatory Access Control (MAC).

One major difference in MAC systems is that the policy is enforced system-wide by an administrator and cannot the changed or overridden by users (as is the case with DAC, where each user controls the policy for his own domain).  This allows for much finer-grained controls of what subject can access what object as well as whether an object can access another object (i.e. process A cannot access process B, even if they are both owned by the same user, unless explicitly allowed by MAC policy).  This idea is much better suited for single-user systems where often the biggest threat doesn't come from another local user, but from something malicious happening inside that one user's domain.  For instance, the user may not want his web browser to be able to interact with his Office suite, etc.  A MAC policy will allow him to specify exactly which files and processes the browser may access.  One can think of it as creating sub-domains within the user's domain (i.e. a "sandbox").

Types of MAC Systems

Not all MAC systems are equal in implementation or functionality (or even in goals).  There are various models of MAC logic like the Bell-La Padula model, the Biba model, and the Clark-Wilson model to name a few.  SELinux, the most popular MAC on Linux systems, mostly follows the Bell-La Padula model (which is focused on classification levels of information -- that is who can read what).  After all, SELinux was designed by the NSA, which has an obvious need for classification levels.  However, SELinux has more functionality than that in practice.  

On the other hand, the Integrity Levels on Microsoft Windows follows the Biba model, which states that a process in a lower (untrusted) domain cannot corrupt or touch a process in a "higher" domain.  Likewise, a subject in a higher domain cannot read an object in a lower domain.  Thus, "no write up, no read down." 

In reality most modern MAC systems (at least on Linux) don't strictly adhere to a single model, thus such a discussion is really only for historical purposes.  SELinux, for instance, has features from both Biba and Bell-La Padula (as well as others).  One of the downsides of SELinux is that it is extremely complicated to write policy for (though this has gotten better over the years).  Furthermore, its focus on MLS makes it more suitable for multi-user systems (i.e. government systems where there are levels of data classification based on security clearances).

AppArmor

This is where AppArmor comes into play.  In my opinion, it is much better suited for the average desktop (or even servers).  It is a path-name based system which makes it much easier to write policy for.  Instead of worrying with "roles" (as RBAC systems) or with MLS or data classification, its focus is simple: a program can only do what an AppArmor policy says it can do and nothing else.  It is essentially highly focused on the principle of least privilege (POLP).  In essence, it does what its name implies -- it puts an "armor" around any application you wish and enforces the policy at the kernel level (being in the kernel is very important or else such a system is subject to being trivially bypassed).  AppArmor can also confine root processes -- that is even if an attacker successfully exploits a root process, he is still confined within the scope of the AppArmor profile (that is, he has root, but can't do much with it).

AppArmor is nice because you can profile what you want and leave everything else alone.  It is recommended to profile everything that touches the network (daemons such as ntp, ssh, as well as applications like browsers and e-mail clients).  The goal is to make an attacker have to go through an AppArmor profile when he enters the system.

Of course, there are things that no MAC system can protect against.  The biggest one is kernel vulnerabilities.  Depending on the vulnerability and how it is exploited, it may allow an attacker to bypass the MAC policy all together.  This is one of the downsides of a monolithic kernel.  However, a MAC policy can greatly reduce the attack surface of the kernel, making the attacker's job of actually *reaching* that vulnerable kernel code more difficult if not impossible.  Until we have high performing microkernels that support the userspace we enjoy in Linux, we will always suffer from this problem of monolithic kernel bloat.

Secondly, AppArmor cannot protect you from weak policy (profiles).  If your profile for the application is too lenient, it may be possible to break out of it.  Also, there are errors you can make in profiles such as using Ux rules where they need not be used.

And finally, AppArmor does nothing to actually stop the profiled application from being exploited.  The idea is to set a policy of what the attacker can do *after* he exploits it.  In many cases it makes his exploit useless since he must operate within the confines of the application itself and can go nowhere else.  If one wants to avoid exploits in the first place, one must tell the app developer to write perfect and 100% mathematically verified code.  Get back to me when that happens (or when pigs fly).  Daniel J. Bernstein, professor of mathematics and a cryptographer at UIC, wrote a very light DNS server of which he gave a security guarantee.  He offered a reward for anyone who could find a security hole in the code.  Guess what?  Someone did and DJB paid out the reward.  The lesson is, if DJB can't do it, probably no one can.  It's just the nature of the computer languages we have today (especially C).

In my next post I will share some AppArmor profiles I have written for various popular applications on Linux.

2 comments:

  1. Very nice post,Can i change my MAC address of my laptop?business security systems ct

    ReplyDelete
  2. Great post on AppArmor. you share some valuable and share worthy points, especially for Mac users. your effort is highly appreciated. i just bookmarked your blog for future posts. thanks.

    ReplyDelete