DAC vs MAC, and Posix Capabilities

The fundamental difference between MAC and DAC that in MAC the administrator/system decides whether a right is shared while in DAC each object that holds a right makes the choice as to whether to delegate it. Traditional capability operating system such as GNOSIS [1] from 1979 are all about being able to delegate only the rights you want to a particular applications, and those applications in turn being able to delegate rights to modules. But they aren't MAC as such, though you could implement MAC on top of them.

The broad concensus at cap-talk is that MAC is usually a liability, as what you really need is finely divisible rights and the overhead of having to change a central security policy means that MAC systems rarely have finely divisible rights (they also agree that POSIX "capabilities" give true capability systems a bad name). Compare the "capabilities" in POSIX to a traditional DAC Capability system such as GNOSIS/KeyKOS. Most capabilities in KeyKOS aren't equivalent to root, or even the user "nobody". Indeed in KeyKOS a process running with the rights of "nobody" would be considered highly privileged, as it has a huge number of rights. For example, it has direct access to the filesystem which is a highly complex, sensitive and hence exploitable piece of code.

The real argument for MAC is that it stops users delegating rights, the first example given was stopping users sharing their maildir. In general malicious users and objects can bypass this by proxying the right, over a side channel if need be. In practice, the benfit of MAC is stopping users from accidentally doing something stupid. But in MAC there is always a trade off between functionality and security. Maybe the user is going away and wants to allow their friend to access their mail to deal with any important issues that crop up. Pathologically, this may encourage the user to give their friend their password, resulting in even worse security.

In true capability systems, objects can delegate precisely those rights required. So, if an object calls "compress(a,b)" compress gets the right to a and b, but does not even know whether a "c" exists. This doesn't come at the cost of functionality as a well written program should never access variables that are out-of-scope, indeed such a program shouldn't even compile. This makes security an "Inexpensive lunch" [2] because you get it for free with a well decomposed object oriented design. Likewise the progam "gedit" would get the right to modify ~/.bashrc if and only if the user selected .bashrc in the file open dialog box; this can be retrofitted to existing POSIX applications, often without even a recompile [3]. In a traditional MAC system the admin would have to decide which rights gedit should have, and would probably just decide to give it rights to the whole home directory.

[1] http://www.cis.upenn.edu/~KeyKOS/Gnosis/Gnosis.html
[2] http://wiki.erights.org/wiki/Walnut/Secure_Distributed_Co...
[3] http://plash.beasts.org/powerbox.html