I know what mandatory access control (MAC) is, but I don't see how it helps. Often it seems to be said that if you have something like SELinux or AppArmor enabled you are magically more secure. And with this, the permissions of something is mandatory and are enforced so that even the owner cannot change them.

However, how is it useful that the owner of a file or something can't use their discretion? All results on $SEARCH_ENGINE seem to say what it is, but not how it helps. This seems quite pointless. Why would they have sufficient permissions with DAC to do that anyway if you don't want them too, and why would you want to remove that and more?

  • 1
    Example: Denying a PDF reader to write arbitrary files while allowing a word processing software to write specific files are real world use cases which can be done with SELinux or Apparmor but not simple file permissions. Commented Mar 12, 2021 at 20:18
  • There are much better ways to do that than SELinux/MAC. Commented Mar 13, 2021 at 4:21
  • 3
    @R..GitHubSTOPHELPINGICE Such as... ?
    – marcelm
    Commented Mar 13, 2021 at 10:09
  • 1
    Running as a user with no permissions to the files to begin with. Running in a user+mount namespace where the files don't exist. Etc. Commented Mar 13, 2021 at 16:38
  • @R..GitHubSTOPHELPINGICE I don't agree that's easier - but certainly jails share a lot of rationale with MAC.
    – vidarlo
    Commented Mar 13, 2021 at 18:34

2 Answers 2


And with this, the permissions of something is mandatory, and are enforced so that even the owner cannot change them.

Imagine mysql running as a certain user. It has to read and write the database, and perhaps some other files - but it has no business poking in a users home directory - even though it may have read access there. A mail server? It has every reason to write to mail files - but no reason to write to a mysql database file. Denying it this permission will ensure that it's unable to - even if it runs as root and has a security issue.

MAC ensures that it can't - even if the user it runs has privileges to perform this action. Furthermore, the user should not have privileges to bypass these protections. Thus, even if the software is compromised, the damage is local to that software.

An other example would be a browser - say chromium. If I deny it permissions outside of /home/*/.config/chromium, /home/*/Downloads/ and so on. Even if a security hole in chromium were to surface, it'd be unable to steal my holiday pictures - because it did not have permissions to read those. Even if an attacker manages to trick me into adding a unsafe extension, it can't access things that the MAC system doesn't give it access to.

You can restrict your applications to what they normally do. Thus, if a security problem occurs, they may still damage the parts they're supposed to access - but will be less likely to damage or ex-filtrate unrelated data.

MAC is another security layer. In addition to the application and file system enforcing permissions, MAC such as SELinux and AppArmor enforces another layer that determines what an application can do or not. It allows more fine grained control than traditional file permissions, and is separate from file permission - so even owner of a file can't directly bypass MAC to give it access.

  • "You can restrict your applications to what they normally do." The problem is that programs sometimes have valid needs to step beyond what you (or the site administrator) considers normal/acceptable. Then your software breaks, but you don't know why.
    – RonJohn
    Commented Mar 13, 2021 at 12:04
  • Most MAC logs denied actions. This is not different from other software troubleshooting, it's just another layer. If you're aware of the layer and know how it works, it's trivial.
    – vidarlo
    Commented Mar 13, 2021 at 12:06
  • 3
    Does this really address the OP question? The key point of MAC is the M, Mandatory. You can achieve everything listed here with a DAC (it's more cumbersome, MACs are more recent and thus more expressive). MAC protect from... yourself. This may seem stupid/useless until you realize most vulnerabilities hijack legit programs into performing malicious actions. MAC is about confinement, it says: No matter who you are, you cannot do this or that. DAC is more like: You can do this or that if you are X or Y. This makes X and Y potential threats if they are fooled. Commented Mar 13, 2021 at 14:23
  • 2
    @davidbak I was thinking about SELinux, specifically. I don't quite understand your quote unless taken in a context that doesn't quite apply to modern everyday computing (insubordination? suppliers controller by the manager?) Commented Mar 13, 2021 at 18:40
  • 2
    BTW this use of MAC is when you install an app on Android and it asks you for permission to use certain resources: The camera, the net, your contacts folder. Unfortunately, as we're discovering, it isn't really sufficient. A photo touchup app. You give the app access to your photos so you can remove redeye, you also give it access to the net so you can download backgrounds. Voila! You just gave it everything it needs to send your private photos somewhere else. We need to invent something new, something better (and easier to use!) to control these things. (Obviously DAC isn't it either)
    – davidbak
    Commented Mar 14, 2021 at 0:39

Multics had both MAC and DAC from the very beginning. Here's a justification for MAC from the paper The Protection of Information in Computer Systems (Saltzer, Schroeder, 1974):

The key reason for interest in nondiscretionary controls is not so much the threat of malicious insubordination as the need to safely use complex and sophisticated programs created by suppliers who are not under the manager's control. A contract software house may provide an APL interpreter or a fast file sorting program. If the supplied program is to be useful, it must be given access to the data it is to manipulate or interpret. But unless the borrowed program has been completely audited, there is no way to be sure that it does not misuse the data (for example, by making an illicit copy) or expose the data either accidentally or intentionally. One way to prevent this kind of security violation would be to forbid the use of borrowed programs, but for most organizations the requirement that all programs be locally written (or even thoroughly audited) would be an unbearable economic burden. The alternative is confinement of the borrowed program, a term introduced by Lampson [61]. That is, the borrowed program should run in a domain containing the necessary data, but should be constrained so that it cannot authorize sharing of anything found or created in that domain with other domains.

(my highlighting)

You must log in to answer this question.

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