Mandatory access control

From Wikipedia, the free encyclopedia
  (Redirected from Mandatory Access Control)
Jump to: navigation, search

In computer security, mandatory access control (MAC) refers to a type of access control by which the operating system constrains the ability of a subject or initiator to access or generally perform some sort of operation on an object or target. In practice, a subject is usually a process or thread; objects are constructs such as files, directories, TCP/UDP ports, shared memory segments, IO devices etc. Subjects and objects each have a set of security attributes. Whenever a subject attempts to access an object, an authorization rule enforced by the operating system kernel examines these security attributes and decides whether the access can take place. Any operation by any subject on any object is tested against the set of authorization rules (aka policy) to determine if the operation is allowed. A database management system, in its access control mechanism, can also apply mandatory access control; in this case, the objects are tables, views, procedures, etc.


In the early 1940s computers had heated glass transistor tubes, Univac Eniac (note: many projects in the United States and England). Errant software could cause the tubes to be destroyed. Soon after replacement, the "kernel" was made to have several privilege rings, the effect was software errors could not cause tube overheating, and which allowed stopping errant programs to avoid "boot strapping" the kernel by hand.

With VLSI, developed in Texas, the Harvard University computer design became the favored design for personal computing (a central CPU ostensibly controlling attachments). The wisdom of privilege rings from the tube days were kept. Studies by Cray supercomputer (the one initiated by State of Texas census bureau) and other ventures tied multiple processors by technologies they created like SCSI (small computer system interface) to a CPU, keeping privilege controls intact for the same reasons. In Motorola and (later) Intel CPU the "privilege rings" are still present, and some used for multi-tasking.

These privilege rings became used to have privilege bits outside the cpu (i.e., on disks) to be used for "user access control" (i.e., rather than for "spin locking"): which is suitable assuming the person does not have physical access, does not betray, and that there are no Bugs in the kernel.

The orange book is associated with MAC but did not coin the term. The book (or notes left in RFCs by) did leave note that security bits (i.e., file permission bits) made by a true CPU layout pc are a practical MAC implementation (where checksum error errors are tolerable, kernel is not buggy, etc.), but also they expressed distance from particular implementation of bits.

In its early days, MAC was closely associated with multi-level secure (MLS) systems and the protection of information related to national security. The Trusted Computer System Evaluation Criteria[1] (TCSEC), the seminal work on the subject which is often referred to as the "Orange Book", defined 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". In this context, the term MAC connoted that the access controls were guaranteed not only in principle, but in fact. Security controls appropriate for MAC were required to be based on a logical rationale that assured that they were enforced with near certainty. Early security strategies[2] enabled enforcement guarantees that were dependable in the face of national lab level attacks. Early hardware-based enforcement implementations of MAC such as Honeywell's SCOMP, USAF SACDIN, NSA Blacker, and Boeing's MLS LAN focused on MLS to protect military-oriented security classification levels with robust enforcement. The hierarchical structure of military security policies and the hardware-based strategies implemented enabled this degree of assurance.

More recently, MAC has evolved out of the MLS niche and has become more mainstream. This evolution is primarily due to the advent of software-based implementations such as SELinux (incorporated into Linux kernels from 2.6), Mandatory Integrity Control (incorporated into Windows Vista and newer), and mandatory schemes derived from the FreeBSD MAC Framework in OS X, iOS, and Junos. These more recent MAC implementations have recognized that the narrow TCSEC definition, focused as it was on MLS, is too specific for general use.[3] These implementations provide more depth and flexibility than earlier MLS-focused implementations,[4][5] allowing (for example) administrators to focus on issues such as network attacks and malware without the rigor or constraints of MLS systems.

This transition from hardware-based enforcement has left the military security niche without the ultra high assurance enforcement products it once had. The departure from strict hardware-based enforcement has relaxed the expectations of the term "mandatory", devolving from a mandate of near absolute enforcement to acceptance of "best effort" enforcement. While software-based enforcement is more flexible, the security technology has not yet produced a software-based enforcement strategy that can enforce a policy with near certainty. This is because it has been much more difficult to be certain about what a software-based system will never do compared to that of hardware-based system.

Implications of the term mandatory[edit]

Mandatory of course means "no means no", by all feasible electro-mechanical ways and means: an "off" setting is treated as a single and central point of authority and allows no electrical or software access, period, exactly as an off transistor does not pass electricity under all thesible circumstances while being the only path to access. (And this was why Univac needed several privelage rings to protect itself: access control relies on error free information but by chance and multitude can be defeated by errors)

In the context of MLS, the term mandatory used with access controls has historically implied a very high degree of robustness that assures that the control mechanisms resist subversion, thereby enabling them to enforce an access control policy that is mandated by some regulation that must be absolutely enforced, such as the Executive Order 12958 for US classified information.

For MAC, the access control decision is contingent on verifying the compatibility of the security properties of the data and the clearance properties of the individual (or the process proxying for the individual). The decision depends on the integrity of the metadata (e.g. label) that defines the security properties of the data, as well as the security clearance of the individual or process requesting access. For example, if a security label can be changed by a user, a surprisingly common vulnerability in some self-proclaimed 'MAC capable' systems, then that user can corrupt the access controls. Security mechanisms that protect such metadata and the access control decision logic from corruption are MAC-critical objects and require appropriate robustness.

The term mandatory in MAC has acquired a special meaning derived from its use with military systems. MAC means access controls that are mandated by order of a government and so 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.

Vendors claiming to enforce MAC are sometimes making claims beyond their capability, and sometimes making claims beyond their understanding. The claim that MAC is enforced implies a claim of very high robustness. Vendors claiming MAC capability do usually have functions that enable defining of MAC privileges and rules but their implementations can be woefully unable to enforce them under even the mildest of attack. Ordinary 'best practices' does not produce software that has this kind of assurance level; in fact, no successful software-only approach has ever been documented. The only approach that has succeeded at protecting MAC controls from subversion has been to design the kernel to maintain a domain for its own execution using highly specialized hardware designed into the microprocessor architecture.[citation needed] Besides its cost, this is often unpopular because it affects portability of the operating system.

Degrees of MAC system strength[edit]

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 a MAC 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 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.[6] 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.

Evaluation of MAC system strength[edit]

MAC (i.e. by hardware support for permission bits and unix support of this) has been and is perfect unless there are physical errors which slip by the hardware / kernel (error checking). Because historic permission bits are too simple to fail, rarely if ever was any device or kernel support released to the public with a MAC bug. Security problems have always been due to distribution (OS) and administrator mis-configuration or lack of understanding. MAC bits are by far the most practical and speedy way to support the specification.

Consumer smart products have things (like graphical desktop, sound) which do not truly support MAC access, or where consumers reject any performance loss of MAC support. Even where MAC can be partly or fully enabled (i.e., in X11) for lacking devices, doing so will break software assuming MAC has been by-passed. DAC (discretionary access control) or no AC are the tradition for some parts of consumer products.

The Common Criteria[7] is based on this science and it intended to preserve the Assurance Level as EAL levels and the functionality specifications as Protection Profiles. Of these two essential components of objective robustness benchmarks, only EAL levels were faithfully preserved. In one case, TCSEC level C2[8] (not a MAC capable category) was fairly faithfully preserved in the Common Criteria, as the Controlled Access Protection Profile (CAPP).[9] Multilevel security (MLS) Protection Profiles (such as MLSOSPP similar to B2)[10] is more general than B2. They are pursuant to MLS, but lack the detailed implementation requirements of their 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 (for example) might comprise an untrusted application where the system should monitor and/or control accesses to devices and files).

Encryption does not qualify as MAC because they can be reverse computed (if public) or cause corruption by mere chance of erroneous string matching (a file permission bit set to no means no, until the cpu sets the bit otherwise: chance matching is not involved). (Some rare crypt implementations might be qualified for some uses)

vs Discretionary Access Control[edit]

With mandatory access control, this security policy is centrally controlled by a security policy administrator; users do not have the ability to override the policy and, for example, grant access to files that would otherwise be restricted. By contrast, discretionary access control (DAC), which also governs the ability of subjects to access objects, allows users the ability to make policy decisions and/or assign security attributes. (The traditional Unix system of users, groups, and read-write-execute permissions is an example of DAC.) MAC-enabled systems allow policy administrators to implement organization-wide security policies. Unlike with DAC, users cannot override or modify this policy, either accidentally or intentionally. This allows security administrators to define a central policy that is guaranteed (in principle) to be enforced for all users.


A few MAC implementations, such as Unisys' 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.

  • Amon Ott's RSBAC (Rule Set Based Access Control) provides a framework for Linux kernels that allows several different security policy / decision modules. One of the models implemented is Mandatory Access Control model. A general goal of RSBAC design was to try to reach (obsolete) Orange Book (TCSEC) B1 level. The model of mandatory access control used in RSBAC is mostly the same as in Unix System V/MLS, Version 1.2.1 (developed in 1989 by the National Computer Security Center of the USA with classification B1/TCSEC). RSBAC requires a set of patches to the stock kernel, which are maintained quite well by the project owner.
  • An NSA research project called SELinux added a Mandatory Access Control architecture to the Linux Kernel, which was merged into the mainline version of Linux in August 2003. It utilizes a Linux 2.6 kernel feature called LSM (Linux Security Modules interface). Red Hat Enterprise Linux version 4 (and later versions) come with an SELinux-enabled kernel. Although SELinux is capable of restricting all processes in the system, the default targeted policy in RHEL confines the most vulnerable programs from the unconfined domain in which all other programs run. RHEL 5 ships 2 other binary policy types: strict, which attempts to implement least privilege, and MLS, which is based on strict and adds MLS labels. RHEL 5 contains additional MLS enhancements and received 2 LSPP/RBACPP/CAPP/EAL4+ certifications in June 2007.[11]
  • TOMOYO Linux is a lightweight MAC implementation for Linux and Embedded Linux, developed by NTT Data Corporation. It has been merged in Linux Kernel mainline version 2.6.30 in June 2009.[12] Differently from the label-based approach used by SELinux, TOMOYO Linux performs a pathname-based Mandatory Access Control, separating security domains according to process invocation history, which describes the system behavior. Policy are described in terms of pathnames. A security domain is simply defined by a process call chain, and represented as a string. There are 4 modes: disabled, learning, permissive, enforcing. Administrators can assign different modes for different domains. TOMOYO Linux introduced the "learning" mode, in which the accesses occurred in the kernel are automatically analyzed and stored to generate MAC policy: this mode can be used as first step of policy writing, making it easy to customize later.
  • Intel and Motorola CPU support MAC in silicon if the "privelaged mode" is entered. After the kernel enters the mode it is trusted to manage multi-tear MAC in silicon to manage multiple programs/users. Kernels are widely know to be released with all kinds of bugs (very few effecting the higher modes, but still).
  • SUSE Linux (now supported by Novell) and Ubuntu 7.10 have added a DAC implementation called AppArmor. AppArmor utilizes a Linux 2.6 kernel feature called LSM (Linux Security Modules interface). LSM provides a kernel API that allows modules of kernel code to govern ACL (DAC ACL, access control lists). AppArmor is not capable of restricting all programs and is optionally in the Linux kernel as of version 2.6.36.[13]
  • Linux and many Unices have MAC for cpu (multi ring), disk, memory; while OS software may not manage privelages well, linux became famous throughout 90's as being more secure and far more stable than non-unix alternatives. Linux distributors disable MAC to being (at best DAC) for some devices - although this is true for any consumer electronics available today free or non-free.
  • grsecurity is a patch for the Linux kernel providing a MAC implementation (precisely, it is a RBAC implementation). Compared to SELinux and AppArmor, grsecurity is not implemented by default in any Linux distribution except for the Tor-ramdisk micro Linux distribution.[14] Hardened Gentoo offers a pre-patched kernel with grsecurity. grsecurity is not implemented via the LSM API.[15]
  • Microsoft Starting with Windows Vista and Server 2008 Windows incorporates Mandatory Integrity Control, which adds Integrity Levels (IL) to processes running in a login session. MIC restricts the access permissions of applications that are running under the same user account and which may be less trustworthy. Five integrity levels are defined: Low, Medium, High, System, and Trusted Installer.[16] Processes started by a regular user gain a Medium IL; elevated processes have High IL.[17] While processes inherit the integrity level of the process that spawned it, the integrity level can be customized on a per-process basis: e.g. IE7 and downloaded executables run with Low IL. Windows controls access to objects based on ILs, as well as for defining the boundary for window messages via User Interface Privilege Isolation. Named objects, including files, registry keys or other processes and threads, have an entry in the ACL governing access to them that defines the minimum IL of the process that can use the object. MIC enforces that a process can write to or delete an object only when its IL is equal to or higher than the object’s IL. Furthermore, to prevent access to sensitive data in memory, processes can’t open processes with a higher IL for read access.[18]
  • FreeBSD supports Mandatory Access Control, implemented as part of the TrustedBSD project. It was introduced in FreeBSD 5.0. Since FreeBSD 7.2, MAC support is enabled by default. The framework is extensible; various MAC modules implement policies such as Biba and Multi-Level Security.
  • Sun's Trusted Solaris uses a mandatory and system-enforced access control mechanism (MAC), where clearances and labels are used to enforce a security policy. However note that the capability to manage labels does not imply the kernel strength to operate in Multi-Level Security mode[citation needed]. Access to the labels and control mechanisms are not[citation needed] robustly protected from corruption in protected domain maintained by a kernel. The applications a user runs are combined with the security label at which the user works in the session. Access to information, programs and devices are only weakly controlled[citation needed].
  • Apple's Mac OS X MAC framework is an implementation of the TrustedBSD MAC framework.[19] A limited high-level sandboxing interface is provided by the command-line function sandbox_init. See the sandbox_init manual page for documentation.[20]
  • SE-PostgreSQL is a work in progress as of 2008-01-27,[21][22] providing integration into SE-Linux. It aims for integration into version 8.4, together with row-level restrictions.
  • Trusted RUBIX is a mandatory access control enforcing DBMS that fully integrates with SE-Linux to restrict access to all database objects.[23]
  • Smack (Simplified Mandatory Access Control Kernel) is a Linux kernel security module that protects data and process interaction from malicious manipulation using a set of custom mandatory access control rules, with simplicity as its main design goal.[25] It has been officially merged since the Linux 2.6.25 release.[26]
  • UFS Unix Filesystems (in general) along with kernels (and hardware) implement multiple-ring MAC (but vary in implementation). The evidence is this: a file bit might become erroneously marked as "access allowed", but if the file is in a directory having "not allowed" bit set, access is still always blocked; which examples one kind of MAC failsafe.

See also[edit]


  1. ^ Trusted Computer System Evaluation Criteria. United States Department of Defense. December 1985. DoD Standard 5200.28-STD. 
  2. ^ Gasser (1988). Building a Secure Computer System. Published by Van Nostrand Reinhold Co. ISBN 978-0-442-23022-7. 
  3. ^ "The Inevitability of Failure" (PDF). National Security Agency. Retrieved 2008-03-15. 
  4. ^ Loscocco, Peter A; Smalley, Stephen D. "Meeting Critical Security Objectives with Security-Enhanced Linux" (PDF). Archived from the original (PDF) on 2008-07-26. Retrieved 2008-03-15. 
  5. ^ Watson, Robert N M. "A Decade of OS Access-Control Extensibility". 
  6. ^ "Technical Rational Behind CSC-STD-003-85: Computer Security Requirements". 1985-06-25. Retrieved 2008-03-15. [dead link]
  7. ^ "The Common Criteria Portal". Retrieved 2008-03-15. 
  8. ^ US Department of Defense (December 1985). "DoD 5200.28-STD: Trusted Computer System Evaluation Criteria". Retrieved 2008-03-15. 
  9. ^ "Controlled Access Protection Profile, Version 1.d". National Security Agency. 1999-10-08. Retrieved 2008-03-15. 
  10. ^ "Protection Profile for Multi-Level Operating Systems in Environments Requiring Medium Robustness, Version 1.22". National Security Agency. 2001-05-23. Retrieved 2008-03-15. 
  11. ^ National Information Assurance Partnership. "The Common Criteria Evaluation and Validation Scheme Validated Products List". Archived from the original on 2008-03-14. Retrieved 2008-03-15. 
  12. ^ "TOMOYO Linux, an alternative Mandatory Access Control". Linux 2 6 30. Linux Kernel Newbies. 
  13. ^ "Linux 2.6.36 released 20 October 2010". Linux 2.6.36. Linux Kernel Newbies. 
  14. ^ "Tor-ramdisk Technical Considerations". Retrieved 2011-04-15. 
  15. ^ "Why doesn't grsecurity use LSM?". 
  16. ^ Matthew Conover. "Analysis of the Windows Vista Security Model". Symantec Corporation. Retrieved 2007-10-08. 
  17. ^ Steve Riley. "Mandatory Integrity Control in Windows Vista". Retrieved 2007-10-08. 
  18. ^ Mark Russinovich. "PsExec, User Account Control and Security Boundaries". Retrieved 2007-10-08. 
  19. ^ TrustedBSD Project. "TrustedBSD Mandatory Access Control (MAC) Framework". Retrieved 2008-03-15. 
  20. ^ "sandbox_init(3) man page". 2007-07-07. Retrieved 2008-03-15. 
  21. ^ "SEPostgreSQL-patch". 
  22. ^ "Security Enhanced PostgreSQL". 
  23. ^ "Trusted RUBIX". 
  24. ^ (Russian) Ключевые особенности Astra Linux Special Edition по реализации требований безопасности информации
  25. ^ "Official SMACK documentation from the Linux source tree". Archived from the original on 2012-09-13. 
  26. ^ Jonathan Corbet. "More stuff for 2.6.25". Archived from the original on 2012-09-12. 


External links[edit]

  • Weblog post on the how virtualization can be used to implement Mandatory Access Control.
  • Weblog post from a Microsoft employee detailing Mandatory Integrity Control and how it differs from MAC implementations.
  • GWV Formal Security Policy Model A Separation Kernel Formal Security Policy, David Greve, Matthew Wilding, and W. Mark Vanfleet.