Ah, the age old promise of MACs: perfectly secure, as long as you don't think very hard about the fact that somebody has to administer the access control rules.
It was straight-forward on the first system to use it: STOP OS on SCOMP & XTS-400. The STOP OS broke OS into various components layered by how privileged they were into four rings with user-mode software on lowest layer. Then, the ring protection by itself prevents (a) writes by untrusted programs to trusted programs' data or code spaces; (b) reads of secrets from privileged programs by untrusted programs. Anything security-critical is mediated by security kernel that is formally specified, verified, analyzed, tested, and pentested against a clear, security policy.
Complexity came when people wanted to apply MAC to poorly architected operating systems and programs. Especially monolithic UNIX. The LOCK program, which I link to in my main reply to OP, invented type enforcement in an effort to express vast majority of security policies for both their clean-slate, high-assurance TCB plus the UNIX VM's they were making for compatibility. Got applied to a BSD in Sidewinder firewall, then applied to microkernels at Utah in form of Flask architecture, and then ported as SELinux to Linux. As you can see, a series of tough compromises from Linux's insecure design plus the fact it was basically an academic hack led to its complexity and issues.
Simpler ones included LOMAC, rule-set based methods, Windows Integrity Control (similar to STOP's), and so on. TOMOYO and AppArmor at least did a learning mode that acceptance testing could feed. Capsicum brings capability-security model to FreeBSD on top of SEBSD enhancements. It's not kludgy MAC or nothing. There's middle ground.
There's two separate issues here, both of which apply:
1. A knob that can't be configured can't be misconfigured (IIRC Debian had a hole in its default selinux config for years that created a vulnerability selinux-less machines didn't have)
2. (This was more what I meant) the promise that makes people like MACs is that you no longer need a single all-powerful root user to do everything (this bleeds into ACLs and capabilities, too), but keeps running into two icebergs:
2a. Somebody still has to administer those controls, and so can effectively become that all-powerful root, and
2b. The only stuff I actually care about is the actual data that the application being sandboxed can access to begin with.
This gives us the particularly pointless exercise in which somebody who steals my laptop can impersonate me on gmail and social media, empty my bank account, and delete all my github repos, but can't change the laptop's time zone. The system files that I can download for free at any time are protected, but the manuscript for my novel is not.
Well. There just aren't many useful caps to begin with. For example, consider backups. You'd want the backup system to have full read access to everything. Well. You can't do that with capabilities. You only get DAC_OVERRIDE, which is one of the many root-equivalent caps in Linux. Probably half of them are.
Even better, in my opinion, is that many of the caps that you would use to sandbox an app (like PID and FS namespaces) require you to have the sysadmin capability set on the process.
Great. You need to give a process more or less root so that it can deny itself privileges.
The idea is probably that the service manager (systemd) manages the NSs for the applications contained therein. systemd of course doesn't have to check it's own privileges.
GNU PIES, however, does check its own privileges. I have no idea why it didn't get a harder look during the init wars. I get that Shepherd "isn't there yet", but IMO Pies is.
Complexity came when people wanted to apply MAC to poorly architected operating systems and programs. Especially monolithic UNIX. The LOCK program, which I link to in my main reply to OP, invented type enforcement in an effort to express vast majority of security policies for both their clean-slate, high-assurance TCB plus the UNIX VM's they were making for compatibility. Got applied to a BSD in Sidewinder firewall, then applied to microkernels at Utah in form of Flask architecture, and then ported as SELinux to Linux. As you can see, a series of tough compromises from Linux's insecure design plus the fact it was basically an academic hack led to its complexity and issues.
Simpler ones included LOMAC, rule-set based methods, Windows Integrity Control (similar to STOP's), and so on. TOMOYO and AppArmor at least did a learning mode that acceptance testing could feed. Capsicum brings capability-security model to FreeBSD on top of SEBSD enhancements. It's not kludgy MAC or nothing. There's middle ground.