Both Mandatory Access Controls and Capabilities allow for fine grained privileges to be assigned to applications irrespective or in place of privileges inherited by the running user.

Is there any practical difference between these two approaches? I understand for example that a capability based operating system can rely on a token being passed while a MAC system such as SELinux can rely on what is essentially an ACL.

In practice however with both techniques an application will be restricted with fine grained privileges. Are there any differences between the approaches from a practical point of view?

  • I've removed my answer - on re-reading, you're asking about capabilities as opposed to POSIX capabilities.
    – user2213
    Nov 24, 2011 at 12:36
  • Mandatory access control (MAC) covers a lot of ground. Can you narrow your question to explain specifically what sort of system you are thinking of? Are you thinking of classical multi-level security systems (e.g., based upon military-style secrecy levels and information flow control)? Are you thinking of SELinux as deployed in Linux distributions (i.e., targeted mode)? Something else? There are significant differences between these different systems, even though they could potentially all be classed as MAC.
    – D.W.
    Nov 26, 2011 at 5:04
  • @D.W. I was thinking of something like SELinux as an example. Nov 26, 2011 at 15:22

5 Answers 5


Capabilities are considered more powerful. They prevent confused deputy attacks, where applications act of behalf of others, and provide a clear paradigm for reducing and delegating permissions. This is important in systems where applications communicate a lot with each other, like Android or microkernel systems. In fact, NICTA advertises that as a result of the seL4 security proof, it became clear that capabilities are essential and they also ported them to the current OKL4. Without capabilities, you need a global namespace so that the Reference Monitor(OS, microkernel) is able to lookup each and every application in the MAC table.

"Capability Myths Demolished" by Miller et.al. gives a good overview of some key concepts. But you may also want to consider the reviews that the paper got from an attempted submission in Usenix Security: http://www.eros-os.org/pipermail/cap-talk/2003-March/001133.html

  • Is that what SELinux for example has, a global namespace where every rule can be checked? Nov 24, 2011 at 13:25
  • AFAIK, SELinux identifies subjects with processes, or more specifically with the path of the program binary that represents the code of the program. So the FS is your global namespace. Following this argument, you may run into problems when you start using chroots with different versions of, e.g., /sbin/mount that are supposed to have different rights, or if you upgrade the binary while its running in background and the new one needs different rights. With capabilities, your chroot can have different rights that are automatically inherited by the chrooted /sbin/mount.
    – pepe
    Nov 26, 2011 at 0:22

The short answer: They are two entirely different kinds of systems. They're just different. Comparing them is a bit like comparing apples and oranges. They are so fundamentally different -- different in so many ways -- that no one-sentence comparison will really do them justice.

Oh, that's not good enough for you? OK, then, here's the long answer.

Background: mandatory access control. In my view, the entire notion of "mandatory access control" (as opposed to "discretionary access control") is incoherent. Access control systems are always mandatory; the whole point of an access control system is to enforce some access policy on subjects. Compliance is not voluntary; subjects are forced to abide by the policy, whether they like it or not. So the entire notion is confused; any access control system always include mandatory elements.

That said, many people use the phrase "mandatory access control" to refer to a class of approaches to security, based upon military-style classification and information flow control. Mandatory access control systems often introduce some hierarchy of labels -- a simple example might be "Public", "Secret", and "Top Secret", or "Low" and "Hi" -- and tag data with these labels. The system then enforces some rules to ensure that anything that's derived from confidential data will also be treated as confidential; these rules typically enforce how labels are assigned and updated as information propagates throughout the system. A typical goal would be to ensure that Top Secret-classified information can never leak out over an unclassified channel

  • (Strictly speaking, this is a "multi-level security" (MLS) systems; while MLS systems are a form of mandatory access control, one could also imagine hypothetical mandatory access control systems that don't use MLS. However, because MLS systems are the classical example of a mandatory access control system, "multi-level security" often gets conflated in many people's minds with "mandatory access control". At risk of causing confusion, I'll continue to use the phrase "mandatory access control" to refer both to the general concept as well as to the particular notion of multi-level security, because this is how the term seems to be used in the literature.)

Bell-Lapadula is an example of a theoretical model that is often considered representative of the mandatory access control approach.

SELinux is sometimes classified as a deployed system that implements mandatory access control, but this may be a bit misleading. SELinux has at least two configurations. In the strict configuration, SELinux enforces information flow control rules to every process running on your system. However, this is too strict for general use. Therefore, this is not how SELinux is deployed in practice. In practice, the Linux distributions that have adopted SELinux have instead deployed it in so-called "targeted" mode. For most intents and purposes, targeted mode limits only certain applications (there are a few global rules that apply to all applications but they are very narrow). Targeted mode consists of a set of ad-hoc rules about what kinds of information flow and accesses those applications can do. It only places restrictions on a subset of applications, and those restrictions are partial. It does not try to provide comprehensive security. It does not try to ensure that, e.g., Top Secret-classified information can never leak. Therefore, SELinux -- as it tends to be deployed today -- is a watered-down version of mandatory access control that falls short of what the original proponents of mandatory access control envisioned.

Object-capability systems. Object-capability systems are an approach to enforcing authorization policies. The core precepts are: access to a particular resource is granted to those who hold a corresponding capability (and only if the capability is held); capabilities can be freely passed from one subject to another; and capabilities are the only means by which access can be obtained.

Object-capability systems are designed to solve a particular problem. The design goal is that the OS should provide a very limited, simple substrate for expressing access control policies. Thus, the OS provides a few very basic primitives (the ability to use a capability, the ability to pass a capability on to another subject), and nothing more. What about applications that need to enforce rich access control policies? Rather than building support into the OS for each individual little thing that some application might want, in an object-capability system the application is empowered to implement its access control needs using the basic primitives provided by the OS. This keeps the interface exposed by the OS simple, while still preserving flexibility and enabling applications to express and enforce complex access policies.

Beware: "POSIX capabilities" are not capabilities. If you'll allow me to take a tangent, I'd like to inject a note of caution. You may have heard of POSIX capabilities. This name is unfortunately and poorly chosen. They are not, in fact, capabilities at all. Rather, the OS identifies a set of a dozen or so special privileges that are typically granted to root in a conventional Unix system, and allows processes to be granted a subset of these privileges. However, they are not held by processes as a capability, and there is no notion of passing them from one process to another. In other words, despite the unfortunately-chosen name, they aren't capabilities at all. Therefore, to prevent confusion, I'd like to exclude them from this discussion entirely (unless you tell me that "POSIX capabilities" is actually what you were interested in learning about).

Comparisons. Let me draw some comparisons and contrasts between mandatory access control and capabilities.

  • Confidentiality? Traditionally, mandatory access control systems have focused on enforcing confidentiality restrictions: e.g., ensuring that classified-Secret data is never leaked to anyone without a Secret clearance. In contrast, object-capability systems usually focus more on integrity and access control.

    One reason for this is covert channels: no access control system can eliminate covert channels, and covert channels allow two colluding parties to conspire to defeat the purposes of traditional mandatory access control systems. If Alice has clearance to access the secret data, and Alice is conspiring with Bob, then Alice can arrange to leak the data to Bob, no matter what any access control system tries to say about this. Object-capability systems recognize this and don't try to prevent it; they subscribe to the slogan "Don't prohibit what you can't prevent". Mandatory access control systems try to prohibit this, even though they can't prevent it, and published work on mandatory access control is often evasive about covert channels or ignores the problem entirely.

  • Feasibility? Unfortunately, traditional mandatory access control policies -- while appealing in their elegance -- have turned out to be not very practical.

    The primary challenge is the phenomenom that "eventually everything floats to Top", meaning that eventually almost everything in your system gets labelled with the top-most confidential label: e.g., Top Secret. Why? Well, imagine a spreadsheet containing some Public data and some Top Secret data. It will get labelled Top Secret. In general, any time you perform any computation that depends upon both secret and non-secret data, mandatory access control systems will label the result as secret. If Alice sends a non-secret message to Bob, and Bob is labelled secret, and Bob returns an acknowledgement back to Alice saying that he received her message, then mandatory access control systems will often label Alice as secret (this is intended to capture the fact that the acknowledgement might convey secret information from Bob to Alice). So basically any time that secret data mixes with non-secret data, it all gets labelled secret, and any time that a subject with access to secret data interacts with a subject with only non-secret data, they both get labelled secret. This acts as a one-way ratchet that causes more and more data/subjects to be labelled as secret. People have observed that, over time, most or all of the system eventually gets labelled as secret, and then the system becomes useless to non-secret users (you might as well have just said that this system is only intended for Top Secret data). This renders mandatory access control systems less useful than one might expect. As a result, traditional-style mandatory access control has seen little deployment.

    Modern mandatory access control systems do try to avoid this problematic phenomenom, by introducing various variations to the basic MLS concept listed above. (For instance, SELinux's targeted mode avoids the "everything floats to Top" phenomenom, by avoiding trying to provide comprehensive information flow protection for all confidential data.) However, these variations on the traditional mandatory access control concept tend to introduce their own problems:

  • Complexity? In principle, both mandatory access control and object-capability systems are built upon a simple and elegant theoretical foundation. However, in the real world, mandatory access control systems are typical forced to depart from this elegant foundation if they want to avoid the "everything floats to Top" phenomenom.

    As a result, deployed mandatory access control systems -- like SELinux -- tend to be extremely complex. Even in its targeted mode, SELinux's access control policy specification runs to something like a hundred thousand lines of access rules. This makes the system hard to understand, when something goes wrong. SELinux is notorious for causing hard-to-debug failures in some use cases, and on Linux distributions that use SELinux, you'll often see people suggesting that users try shutting off SELinux if they run into a hard-to-diagnose system administration problem.

    So far, object-capability systems as implemented retain much of the elegance and simplicity of their theoretical foundations, so they don't seem to suffer from this complexity problem as much. However, we don't have as much practical experience with object-capability systems, so it is hard to know for sure whether this early experience will hold up.

  • Who sets policy? In mandatory access control systems, usually it is envisioned that some omniscient and benevolent system administrator will establish the access control policy that everyone must abide by. However, in practice, this can get really annoying. I'm sure we've all had the experience where some firewall or security system prevents us from sharing data with someone else, or some company security policy makes it hard for us to grant access to someone we're working with. What do you do when that happens? Why, send it in an email attachment, of course. In other words, having a system administrator set the security policy for everyone often fails to reflect users' actual needs, and the result is that users work to bypass the security.

    SELinux is similar. In SELinux's targeted mode, the idea is that omniscient and benevolent SELinux experts will establish an access policy for each application you might ever install, specifying what files and resources that application is permitted to access. These policies have to be based upon the SELinux experts' guesses and predictions about how you might use the application, and what you the application might consequently need to access. However, in real life, SELinux experts are not omniscient, and sometimes they fail to anticipate how people might use their applications -- causing the SELinux policy to occasionally block legitimate program behavior.

    (In principle, end users can write their own SELinux policies and modify the default system policy. In practice, not so much. The level of complexity makes this way beyond the means of most end users. In practice, I would expect that 99.99% of SELinux distributions use the default policy, because modifying it in any substantive way is too difficult.)

    In contrast, object-capability systems don't rely upon an expert and well-informed system administrator to set the policy for everyone. Instead, each application is empowered to enforce its own access policy, based upon the needs of that application. Thus, access control is not specified in advance by a single central party; instead, it is determined, on the fly, by the combined actions of application developers and users.

  • Least privilege? One of the benefits of object-capability systems is that they tend to guide application developers towards designs that respect the principle of least privilege. Because the default is that each application receives no access, except for whatever it capabilities it is able to acquire from other sources, this tends to lead towards designs where each application receives no more privilege than they need, and where the same is recursively true of components and subcomponents of the application.

    Some mandatory access control systems also try to enforce the principle of least privilege. For instance, in SELinux's targeted mode, SELinux experts analyze each covered application to determine what actions it might legitimately perform and what security privileges it needs to be granted to perform those actions. Then, these experts write a system security policy which specifies, e.g., the list of files and network sockets and other resources that, e.g., sendmail is permitted to access. That policy is distributed with your Linux distribution and is the same for everyone. In principle, this can also move us closer to the principle of least privilege, but it scales poorly: it requires a handful of experts to write rules for every application covered, so they can cover only a subset of applications (hence the "targeted" mode); it is trying to restrict legacy applications, in whatever form they come, which often means that no useful restrictions can be applied (try thinking about how to write a set of SELinux rules to limit emacs; what set of files are you gonna allow it to access? the only sensible answer is "everything", which defeats the principle of least privilege), whereas object-capability systems can do better by guiding application developers to write their applications in different ways.

  • Deployment experience? We have more experience with deploying mandatory access control systems than with object-capability systems. The conventional wisdom says that traditional mandatory access control systems are usually too restrictive and often prevent people from achieving legitimate tasks, though this doesn't apply to SELinux's targeted mode. The conventional wisdom says that object-capability systems cannot support legacy code well and require us to start over from scratch and re-design and re-implement our entire system and all applications running on it; this is probably the biggest shortcoming of object-capability systems.

There is a lot more to be said, and there is a lot written on capability-based security, object-capability systems, and mandatory access control. This answer only scratches the surface. I suggest you do some background reading. Then, if there is any aspect you'd like to learn more about, try asking a more focused question. Tell us a little bit about your particular application domain, about your requirements/goals/concerns, and what you've read so far, and then we can give you some more detailed advice. Or, tell us more about what specifically you'd like to know, and we can give you some reading recommendations.

  • Just some notes - all targeted apps are confined (they're subject to global booleans such as not mmap()ing low memory addresses), it's just that unconfined_t can do most things. Targeted non-unconfined_t apps are very much confined; they just don't do MLS. In the interests of adding balance, it is also possible to alter and/or amend your own SELinux policy(ies) if you wish, although it is complex. SELinux's MLS works by assigning clearance levels (level range, cats) to roles - if an instance touches a high level it cannot write down, but provided you don't interact with ...
    – user2213
    Nov 26, 2011 at 6:30
  • ... objects in the higher end of the clearance range, you're ok.
    – user2213
    Nov 26, 2011 at 6:31
  • Thanks for sharing your reactions and comments, @Ninefingers. I've revised my answer to address your comments. Would you consider upvoting it, if you feel that the answer is useful?
    – D.W.
    Nov 26, 2011 at 10:56
  • @D.W. That is an extremely in depth answer, so thankyou and I look forward to reading through it properly when I have time. I just want to note I was only asking about differences from a practical/abstracted viewpoint, so not sure if your answer was more in depth than that as I haven't read it yet. Nov 26, 2011 at 15:25
  • @D.W. You talk about MAC in the context of traditional MLS and cover the problem of everything floats to the top. In an implementation of MAC such as SELinux where the focus is often on restricting damage in the event of an attack/successful exploit, I would assume the everything floats to the top is not a problem. In which case, what problems then occur from using MAC for that context? Should this perhaps be a separate question? Nov 28, 2011 at 16:09

Since I first misinterpreted which capabilities you meant (sorry, Linux head on!) I'll go in with another answer as I'm not sure anything yet clears it up for me personally.

First up, the way things stand in access control land.

  • Discretionary Access Control is so called because access controls are delegated amongst certain types of subjects. Specifically, one sort of subject is a user and another is a program. When a user runs a program, the program "inherits" the permissions of the user on principle.
  • Mandatory Access Control is more fine grained. Each process (or thread, or some more fine grained definition of subject) is given their own permissions and do not inherit (hence mandatory) anything from the user who ran them (in theory). Crucially, they do not inherit except as specified in the policy provided. The cornerstone of this area is the concept of Type Enforcement - that paper's ideas look very similar to SELinux policies, as you have no doubt gathered. The basic concept is that types can be quite wide, or quite narrowly scoped and you give process or application domain (subject) access to types (object collections).

    Whilst MLS, MCS etc are closely associated with MAC because you often want to extend types and domains with either additional category access or no-read-up/no-write-down or both, such systems are not MAC without TE. An example of this is Mandatory Integrity Control, a system in Windows implementing a basic no-read-up, no-write-down permissions, but no TE. Another link on TE.

  • RBAC is similar but different to the above two. So I don't diverge; think user groups on Windows.

In all of these cases your process to access a protected resource goes like this:

  1. Request resource.
  2. Enter OS. OS looks at ACL, decides if access is allowed.
  3. OS responds. Process then works out the difference.

Conceptually, this is like requesting what you need via the telephone. The above systems all work on this basis - you ring up, the operator listens to your question, puts you on hold, consults the boss/some records and comes back with a response.

Capabilities are different. Capabilities are like having a pass for work. When you show up waving a pass with the right number on it, it gets you where you need to go. Actually, to extend it properly, it's more like having multiple passes, one for each need. How granular those needs are is a system design choice, so to answer your question right now - both systems will allow you to constrain processes over and above what DAC does.

The thing is - you might have thought "well, turning up with my pass, it still needs to be checked, which still means a telephone call" (into the operating system to check). Yes it does; but here's the flip side of a capability based system:

  • That token must be unmodifiable by user processes. The analogue here is write-once storage that the end user cannot tamper with. Like guaranteeing such security, this is a hard problem.
  • Passing the token on must work, just like handing your pass to somebody else will. If you think about it this makes sense - at some point, someone, somewhere, a trusted person had to create all the necessary passes and start handing them out.

Protecting these capabilities held by a program is the tricky part. Indeed, hardware extensions have been discussed, but rarely implemented. As this.josh describes (+1) describes, L4.sec uses IPC to transfer capabilities. Given IPC is a function provided by the L4 supervisor core for the rest of the system to work (L4 is a microkernel and so most of the system relies on IPC), that supervisor core can use IPC to check the integrity of the capabilities as they are in transit and apply them to the receiving process.

Anyway, back on topic - capability-based systems require that capability management is bulletproof. If you hold the token, you are to be trusted.

Do they look the same and smell the same? Well it's all a form of access control on the surface, but the underlying mechanism is a completely different concept. In one system, you check requests; in the other tokens are the keys and you defend the integrity of those keys with your life.

  • "look the same and smell the same" - They have fundamental, deep differences in their semantics regarding delegation. In object-capability systems, if Alice has a capability that lets her access resource R, then she can freely share that capability with anyone she can communicate with; the system makes no attempt to prohibit this, on the contrary it is explicitly supported. In MAC/MLS systems, this is not the case (not in general); MAC/MLS systems may prohibit this kind of delegation (though they cannot prevent it if Alice and Bob are sufficiently determined).
    – D.W.
    Nov 26, 2011 at 5:14
  • Indeed, as I've explained. I asked do they? not they do because from a very simplistic perspective (until you really think about the consequences) they look identical. However, as you and I say - Passing the token on must work, just like handing your pass to somebody else will. I haven't talked much about delegation, but if you extend the handing your pass out model it's a logical conclusion.
    – user2213
    Nov 26, 2011 at 5:23
  • Perhaps you might want to answer your own question, then, in the interests of clarity. How would you answer your question? Your answer gives me the (perhaps mistaken) impression that your answer would be "well, they're pretty similar, and any differences are mostly inconsequential". In contrast, my answer to the question "Do they look the same and smell the same?" would be: "They may look the same on first glance, but they are not the same; they are different at a fundamental level. It is not merely a different mechanism; the semantics are different in an important way."
    – D.W.
    Nov 26, 2011 at 5:27
  • Ok - I've made the sentence following the question more pronounced so it doesn't understate the difference quite so much.
    – user2213
    Nov 26, 2011 at 5:32
  • Protecting a capability from modification is just like protecting your Linux App from modifying its UID/GUID in some Linux kernel data structure; not much magic involved. In L4, the Apps are simply not given the actual tokens but only references/handles to some protected kernel structure.
    – pepe
    Nov 27, 2011 at 1:23

MAC, in its academic form, is not about access control but about information flow. This is a fundamentally different approach than capabilities. MAC aims to prevents information flow from high to low levels or from low to high, depending on if you're worried about integrity or confidentiality. It's hierarchical that way. Capabilities are not as far as I understand; they simply define actions an object is allowed to perform in a flat model.


On a practical level MAC (as implemented in SELinux) requires all objects (files, directories, processes, and users) in the system to be labeled. A default label is given to objects not otherwise specified. It also requires a policy describing what types of access labeled objects are allowed. A monitor watches access requests and compares labels to the access requested. A new type of object requires a rewrite of the policy and potentially a relabeling of all objects on the system.

Capabilities (as implemented in L4RE) requires individual programs or services to explicitly state their needs for resources (memory, processing, I/O) and which programs of services are allowed access. The communication channel between processes is monitored and access through IPC is allowed or declined based on which program the sender and reciever of the message belong to and what capabilities each program has granted to other programs.

MAC requires a high-level architect to describe the entire system but allows design to be focused on a few specific high value controls. However the cost for significant change to the system is high.

Capabilites required a low level view of how every program interacts with other programs in general. It's initial cost is high but its responce to significant change is low.

In a MAC system like SELinux you can prevent say, Firefox from having write access to arbitrary folders.

With SELinux you can prevent Firefox (or other unauthorized applications) from having write access to folders with a specific label. Other folders may have a label that allows Firefox to have access.

Would this not work in a capability based operating system if the application requested that access as a capability upfront? Would there be a way to limit such access in a capability based operating system?

In a capability based operating system whoever implements the filesystem (not the kernel) can provide a capability allowing control over individual folders. The filesystem could delegate it's capability to a utility allowing a user to set access on a individual folder. Thus a user could specify that any web browser application is not allowed access to write to a folder or set of folders. Defining a general class of web browsers as processes that generate and consume HTML may be easier than trying to specify Firefox.

Notice that the capability based OS does not necessarily have a hierarchy of users (administrator, root, application user, etc). Limiting access is focused on preventing individual processes from interfering with the correct working of the kernel and other processes. Allowing access takes coordination between two processes.

A text editor must know how to request write access to a folder from a file system and the filesystem must know how to grant write access to a text editor but deny write access to a web browser. There is still the implicit notion of a policy in which a service (file system) grants access for condition 1 (text editor) and denys access for condition 2 (web browser).

  • Great answer! It's fair to say then that in a capability based operating system, the onus is on application developers to make sure they have access? Nov 25, 2011 at 7:54
  • Also, I just want to check my understanding with something. In a MAC system like SELinux you can prevent say, Firefox from having write access to arbitrary folders. Would this not work in a capability based operating system if the application requested that access as a capability upfront? Would there be a way to limit such access in a capability based operating system? Nov 25, 2011 at 7:56
  • Your description of MAC (first paragraph) is generally accurate, but your description of capabilities (second paragraph) is not accurate. Read up on object-capability systems.
    – D.W.
    Nov 26, 2011 at 1:34

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .