Editing Mandatory access control (section)

== History and background ==
Historically, MAC was strongly associated with [[multilevel security]] (MLS) as a means of protecting [[Classified information in the United States|classified information of the United States]]. The [[Trusted Computer System Evaluation Criteria]] (TCSEC), the seminal work on the subject and often known as the Orange Book, provided the original definition of MAC as "a means of restricting access to objects based on the sensitivity (as represented by a label) of the information contained in the objects and the formal authorization (i.e., clearance) of subjects to access information of such sensitivity".<ref>{{Cite web |date=15 August 1983 |title=Trusted Computer Evaluation Criteria |url=https://csrc.nist.gov/csrc/media/publications/conference-paper/1998/10/08/proceedings-of-the-21st-nissc-1998/documents/early-cs-papers/dod85.pdf |url-status=live |archive-url=https://web.archive.org/web/20230413225857/https://csrc.nist.gov/csrc/media/publications/conference-paper/1998/10/08/proceedings-of-the-21st-nissc-1998/documents/early-cs-papers/dod85.pdf |archive-date=13 April 2023 |access-date=25 June 2023 |publisher=[[National Institute of Standards and Technology]]}}</ref> Early implementations of MAC such as [[Honeywell]]'s SCOMP, [[USAF]]'s [[SACDIN]], [[NSA]]'s [[Blacker (security)|Blacker]], and [[Boeing]]'s MLS LAN focused on MLS to protect military-oriented security classification levels with robust enforcement.

The word "mandatory" in MAC has acquired a special meaning derived from its use with military systems. In this context, MAC implies an extremely high degree of robustness that assures that the control mechanisms can resist any type of subversion, thereby enabling them to enforce access controls that are mandated by the order of a government such as the [[Executive Order 12958]]. Enforcement is supposed to be more imperative than for commercial applications. This precludes enforcement by best-effort mechanisms. Only mechanisms that can provide absolute or near-absolute enforcement of the mandate are acceptable for MAC. This is a tall order and sometimes assumed unrealistic by those unfamiliar with high assurance strategies, and very difficult for those who are.

In some systems, users have the authority to decide whether to grant access to any other user. To allow that, all users have clearances for all data. This is not necessarily true of an MLS system. If individuals or processes exist that may be denied access to any of the data in the system environment, then the system must be trusted to enforce MAC. Since there can be various levels of [[Classified information|data classification]] and user clearances, this implies a quantified scale for robustness. For example, more robustness is indicated for system environments containing classified "Top Secret" information and uncleared users than for one with "Secret" information and users cleared to at least "Confidential." To promote consistency and eliminate subjectivity in degrees of robustness, an extensive scientific analysis and risk assessment of the topic produced a landmark benchmark standardization quantifying security robustness capabilities of systems and mapping them to the degrees of trust warranted for various security environments. The result was documented in CSC-STD-004-85.<ref name="Ref_1985">{{cite web|url=http://csrc.nist.gov/secpubs/rainbow/std004.txt |title=Technical Rational Behind CSC-STD-003-85: Computer Security Requirements |date=1985-06-25 |accessdate=2008-03-15 |url-status=dead |archiveurl=https://web.archive.org/web/20070715134110/http://csrc.nist.gov/secpubs/rainbow/std004.txt |archivedate=July 15, 2007 }}</ref> Two relatively independent components of robustness were defined: ''Assurance level'' and ''functionality''. Both were specified with a degree of precision that warranted significant confidence in certifications based on these criteria.

The [[Common Criteria]] standard<ref name="Ref_a">{{cite web | url = http://www.commoncriteriaportal.org/ | title = The Common Criteria Portal | accessdate = 2008-03-15 | archive-url = https://web.archive.org/web/20060718074701/http://www.commoncriteriaportal.org/ | archive-date = 2006-07-18 | url-status = dead }}</ref> is based on this science and it intended to preserve the assurance level as [[Evaluation Assurance Level|EAL levels]] and the functionality specifications as [[Protection Profile]]s. Of these two essential components of objective robustness benchmarks, only EAL levels were faithfully preserved. In one case, TCSEC level C2<ref name="Department1985">{{cite web | url = https://fas.org/irp/nsa/rainbow/std001.htm | title = DoD 5200.28-STD: Trusted Computer System Evaluation Criteria | author = US Department of Defense | date = December 1985 | accessdate = 2008-03-15}}</ref> (not a MAC-capable category) was fairly faithfully preserved in the Common Criteria, as the [[Controlled Access Protection Profile]] (CAPP).<ref name="Ref_1999">{{cite web | url = http://www.niap-ccevs.org/cc-scheme/pp/pp.cfm/id/PP_OS_CA_V1.d/ | title = Controlled Access Protection Profile, Version 1.d | date = 1999-10-08 | publisher = National Security Agency | accessdate = 2008-03-15 | archive-url = https://web.archive.org/web/20120207001837/http://www.niap-ccevs.org/cc-scheme/pp/pp.cfm/id/PP_OS_CA_V1.d/ | archive-date = 2012-02-07 | url-status = dead }}</ref> MLS Protection Profiles (such as MLSOSPP similar to B2)<ref name="Ref_2001">{{cite web | title = Protection Profile for Multi-Level Operating Systems in Environments Requiring Medium Robustness, Version 1.22 | url = https://www.commoncriteriaportal.org/files/ppfiles/PP_OS_ML_MR_V1.22.pdf | publisher = National Security Agency | date = 2001-05-23 | accessdate = 2018-10-06}}</ref> is more general than B2. They are pursuant to MLS, but lack the detailed implementation requirements of their [[Trusted Computer System Evaluation Criteria|Orange Book]] predecessors, focusing more on objectives. This gives certifiers more subjective flexibility in deciding whether the evaluated product’s technical features adequately achieve the objective, potentially eroding consistency of evaluated products and making it easier to attain certification for less trustworthy products. For these reasons, the importance of the technical details of the Protection Profile is critical to determining the suitability of a product.

Such an architecture prevents an authenticated user or process at a specific classification or trust-level from accessing information, processes, or devices in a different level. This provides a containment mechanism of users and processes, both known and unknown. An unknown program might comprise an untrusted application where the system should monitor or control accesses to devices and files.

A few MAC implementations, such as [[Unisys]]' [[Blacker (security)|Blacker]] project, were certified robust enough to separate Top Secret from Unclassified late in the last millennium. Their underlying technology became obsolete and they were not refreshed. Today there are no current implementations certified by [[TCSEC]] to that level of robust implementation. However, some less robust products exist.