[nickpsecurity]

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.