MAC

A concept called Mandatory Access Control (MAC) is a hallmark of "secure operating systems". And it really makes them different. Though it has been around since the 80's, MAC is still (literally) an obscure methodology. It based on universal labeling scheme that can be considered as assigning domains (security clearances) to subjects and security classification (types, or classification labels) to objects.

The subject (a user, process, or administrator) may be able to access a file, but, because the file retains its classification label, they may not be able to transfer it to another user, or use any system utilities to copy it from the system. The system recognizes the label on the file, and will not allow the file to be read or otherwise processed by a user or process of lesser clearance. The system will check the file for its classification, and deny another process access to the file unless the process has adequate clearance.

Note that this is different from regular Unix permissions? Any user with individual or group-based ownership of the file can modify regular Unix permissions. Regardless of the information's sensitivity in a file, it can be copied, e-mailed, or read by a user if the file's permissions (read, write, execute, relative to the user, their group, and Everyone) allow it.

All subjects (a user, process, or administrator) are assigned domains, which can be thought of as security clearances, and all objects are assigned types, which can be thought of as security classifications. Security policies are created based upon the sensitivity of the object not at the discretion of the user that receives it.

Contents

The need for a mandatory access control (MAC) mechanism arises when the security policy of a system dictates that:

1. Protection decisions must not be decided by the object owner.
2. The system must enforce the protection decisions (i.e., the system enforces the security policy over the wishes or intentions of the object owner).

The POSIX.6 standard provides support for a mandatory access control policy by providing a labeling mechanism and a set of interfaces that can be used to determine access based on the MAC policy.

In a MAC system, if a file has been given a specific level of sensitivity (or context), then the system will not allow certain users, programs, or even administrators to perform operations on the file. Though this may sound like a subtle difference, imagine you were able to set a log file's sensitivity higher than that of the mailer program. Though you could read, write, and copy the file as needed, not even an administrator could email the file to another system because the mailer lacks the clearance to handle information with your file's level of classification. It is a shift in perspective from using users like "nobody", "uucp", "www" and their accompanying group ID's to separate duties on the system, to requiring that each file on the system have authoritative security information about itself.

Mandatory Access Control and Role-Based Access Control Revisited - Osborn (ResearchIndex)

Security in Open Systems

• Determining MAC Access

Determining MAC Access

The functionality provided by the interfaces to support MAC is used to determine the access of objects by subjects. The POSIX.6 standard defines a subject to be an active entity that can cause information to flow between controlled objects. The POSIX.6 standard further specifies that since processes are the only such interface-visible element of both the POSIX.1 and POSIX.6 standards, processes are the only subjects treated in POSIX.6 MAC. Objects are defined by POSIX.6 as the interface-visible data containers, i.e., entities that receive or contain data to which MAC is applied. POSIX.6 specifies that objects are files (this includes regular files, directories, FIFO-special files, and unnamed pipes), and processes (in cases where a process is the target of some request by another process). POSIX.6 also specifies that each subject and object shall have a MAC label associated with it at all times.

The POSIX.6 standard does not define a mandatory access control policy per se, but does define the restrictions for access based upon the comparison of the MAC label associated with the subject and the MAC label associated with the object. The first general restriction states that unprivileged processes (subjects) cannot cause information labeled at some MAC label (L1) to become accessible to processes at MAC label (L2) unless L2 dominates L1 (see Section 4.6.2 for the definition of ``dominates''). This restriction is further defined with regard to accessing files and other processes. The restrictions placed on file manipulation (reading, writing, creating, etc.) are those that are generally accepted when implementing a MAC policy:

1. to read a file, the label of the process must dominate the label of the file.
2. to write to a file, the label of the process must be dominated by the label of the file (The POSIX.6 standard specifies that dominance equals equivalence - if the labels are equal, then each is considered to be dominant to the other).

For example, a user who is running a process at Secret should not be allowed to read a file with a label of Top Secret. Conversely, a user who is running a process with a label of Secret should not be allowed to write to a file with a label of Confidential.

The POSIX.6 restriction for assigning labels to newly created files is that the new file must have a label that is dominant to the label of the subject, although the POSIX.6 interfaces only allow the label to be equal to that of the process creating the new object. This restriction forces implementations to not allow processes to create files at a ``lower'' label. For example, a process with a label of Top Secret should not be allowed to create a file with a label of Secret. There are analogous restrictions on object access when the object is a process as mentioned above.

Interfaces are provided that allow processes to retrieve, manipulate, compare, set and convert MAC labels. Consistent with the model for using opaque data structures, a label is not manipulated directly but is copied into a working storage area and manipulated there. When the label is no longer requested, the label is written back to its permanent storage area.

class-09-mandatory-access-control

Mandatory Access Control (MAC), trusted OS features

Reading: Pfleeger, Chap 7
_DoD Trusted Computer System Evaluation Criteria_
http://csrc.ncsl.nist.gov/secpubs/rainbow/std001.txt
Bell-LaPadula model:
http://seclab.cs.ucdavis.edu/projects/history/papers/bell76.pdf

* access control policy - MAC vs DAC
DAC - owner or creator decides access policy
MAC - site decides policy (all data owned by site)

* assumptions of military security
stakes are very high (national security)
costs are less important
try hard for "perfect security"
focus on data confidentiality, not integrity - BAD

* "site" or facility policy must be enforced
all data is owned by the "site", not by the users
site policy must override user's wishes
users should not be able to give away access

* DoD security classification system
security levels - ordered
security "categories" - non-ordered

* security levels
top secret (TS)
secret (S)
confidential (C)
"FOUO"
unclassified (U)
DoE uses different system
NATO, UK, others use similar systems

* security categories - non-hierarchical
orthogonal to levels
embody "need to know"
unified categories = caveats + code words + compartments + handling markings
each one is a "bit" that relates to a domain of information (project, technology)

* people and systems - trust
only "trusted" people have access
implies only "trusted" systems can contain
what is trust, really? (Snowman, Hansen, etc.)

* trust for people
successful investigation leads to level of trust
formalized in a security clearance (level)
"need to know" is "orthogonal" - categories
security clearance is security level + (optional) categories

* trust for systems
"accreditation" leads to "facility clearance"
based on adherence to policies
" " some testing
" " some assumptions about systems' capabilities
is a formal, expensive process

* objects, subjects and rules
objects have sensitivity labels
subjects have sensitivity "rights"
rules - how may subjects access objects?

* one policy - Bell-LaPadula model
a mandatory confidentiality policy
attempts to embody military classification rules
formally specified, "proven"
basis for almost all MAC work since 1977
a lattice model - requires some comparison operator
"dominance"

* Bell-LaPadula model - assumptions
every object has a label
every subject has a "label"
some trusted mediator checks *every* access by subject to object
two rules - simple security and *-prop

* labels and "clearances"
generally, use "sensitivity level" for both subjects and objects
label = level + compartments
label stored with each object
subject gets label from authenticated user's clearance
"subject acquires user's credentials"

* what is dominance?
for A >= B to be true
level(A) >= level(B) AND
all compart(B) are in compart(A)
[means B is a subset of A]

* simple security
to read, C(s) >= C(o)
no read from higher
may read things at the same level or lower
"can't see things you shouldn't"
pure confidentiality

* "*-property"
to write, C(s) <= C(o)
no write-down
"can't give away information"
"can't change classification (down)"
enforces classification rules and behavior
prohibits high-level (trusted) subject from going around rules

* insert some B-L examples here...

* What is missing from B-L model?
it is a confidentiality model only
"bad" data can still be propagated around
need integrity

* "Biba integrity" model
is the mirror of B-L
has simple integrity
"no read from lower integrity"
has integrity *-property
"no write to higher integrity"

* "real" security
B-L for confidentiality
Biba for integrity
DAC for finer-grained control

* B-L implemented in:
Multics - 1976
SCOMP - late 1970s
KSOS - late 1970s
KSOS-32 - 1980s
VAX Security Kernel - 1980s
Tmach
UNICOS (Cray UNIX) - early 1990s
Trusted Solaris - late 1990s

* Biba implemented in:
KSOS and KSOS-32

MAC in Linux

During the three days of the USENIX Annual Technical Conference, I attended a number of sessions focusing on security issues and I sat in on a few of the Guru Is In gatherings. There were about 60 different technical sessions, of which about 16 focused on security and privacy. There were ten scheduled Guru Is In sessions, of which four were on security topics.

Tim Fraser of NAI Labs (Network Associates, Inc.) gave a talk in the Freenix MAC Security grouping entitled "LOMAC: MAC You Can Live With." LOMAC is a security enhancement for Linux kernels that works by applying MAC (Mandatory Access Control) techniques to existing Linux modules. LOMAC offers MAC integrity protection to Linux in a form that:

• Can be applied to standard kernels
• Is compatible with existing applications
• Requires no site-specific configuration
• Is largely invisible to users

LOMAC divides the system into two levels of integrity (a high level of critical system components and a low level of the remaining components) and ensures that data does not flow from low-level to high-level files. Two of the main problems NAI Labs dealt with in implementing LOMAC were gaining supervisory control over kernel operations and mapping security attributes to files. Performance is always a concern with additional security modules or enhancements. In performance tests, LOMAC appears to have a relatively small affect on the performance, even though the code has not yet been optimized.

LOMAC can be downloaded under the GNU General Public License.

The second talk in the Freenix MAC Security grouping was "TrustedBSD: Adding Trusted Operating System Features to FreeBSD" by Robert Watson of the FreeBSD project. TrustedBSD is an ongoing effort to integrate a number of trusted operating system features into the FreeBSD OS. These features include:

• Improved security consistency and correctness
• Improved security abstractions and modularity
• General services to support security requirements
• Fine-grained Discretionary Access Control
• Fine-grained privilege model
• Mandatory Access Control (MAC)
• Plugability
• Documentation and education

In addition to needing documentation for developers and users, there's a need for an overall security architecture document. New features are being included in FreeBSD 5.0, and there will be a more complete integration in FreeBSD 6.0. For more information, go to the TrustedBSD Web site. As features mature, they are integrated into the FreeBSD distribution.

The third MAC Freenix session was: "Integrating Flexible Support for Security Policies into the Linux OS" by Stephen Smalley (the presenter) and Peter Loscocco.

This session was about the flexible MAC architecture (FLASK, or Flux Advanced Security Kernel) that the National Security Agency (NSA) has implemented for Linux. NAI Labs has developed an accompanying sample security policy configuration based on FLASK. The NSA implementation of this is named SELinux (Security Enhanced Linux).

Some key points:

• MAC, in contrast to DAC (Discretionary Access Control) is essential for secure operating systems. DAC decisions are based on user identity and ownership, and not on user role, function and trustworthiness of the program, and integrity of the data.
• Policy definitions must be kept separate from the enforcement mechanisms.
• MAC access decisions are based on labels that contain the security-relevant information.
• A system security policy administrator defines the MAC policy, which then is enforced over all the processes and objects in the system.

Performance is always a consideration when adding modules. When SELinux was compared with an unmodified Linux 2.4.2 kernel, there was a measurable degradation of performance, but not enough that users would notice. Developers are working on performance enhancements.

NEWS CONTENTS

Old News

MAC

Mandatory Access Control (MAC) ensures that the enforcement of organizational security policy does not rely on voluntary user compliance. MAC secures information by assigning sensitivity labels on information and comparing this to the level of sensitivity a user is operating at. In general, MAC access control mechanisms are more secure than DAC yet have trade offs in performance and convenience to users. MAC mechanisms assign a security level to all information, assign a security clearance to each user, and ensure that all users only have access to that data for which they have a clearance. MAC is usually appropriate for extremely secure systems including multilevel secure military applications or mission critical data applications. A MAC access control model often exhibits one or more of the following attributes.

• Only administrators, not data owners, make changes to a resource's security label.
• All data is assigned security level that reflects its relative sensitivity, confidentiality, and protection value.
• All users can read from a lower classification than the one they are granted (A "secret" user can read an unclassified document).
• All users can write to a higher classification (A "secret" user can post information to a Top Secret resource).
• All users are given read/write access to objects only of the same classification (a "secret" user can only read/write to a secret document).
• Access is authorized or restricted to objects based on the time of day depending on the labeling on the resource and the user's credentials (driven by policy).
• Access is authorized or restricted to objects based on the security characteristics of the HTTP client (e.g. SSL bit length, version information, originating IP address or domain, etc.)

Mandatory Access Control (MAC)

Sponsored by DARPA and Network Associates Laboratories. Contributed by Robert Watson.

FreeBSD 5.0 includes a new kernel security framework, the TrustedBSD MAC Framework. The MAC Framework permits compile-time, boot-time, and run-time extension of the kernel access control policy, and can be used to load support for Mandatory Access Control (MAC), and custom security modules such as hardening modules. The MAC Framework is currently considered to be an experimental feature, and should not yet be used in production environments without careful consideration. It is anticipated that the MAC Framework will be appropriate for more widespread production use by FreeBSD 5.2.

When configured into a kernel, the MAC Framework permits security modules to augment the existing kernel access control model, restricting access to system services and objects. For example, the mac_bsdextended(4) module augments file system access control, permitting administrators to provide a firewall-like ruleset constraining access to file system objects based on user ids and group membership. Some modules require little or no configuration, such as mac_seeotheruids(4), whereas others perform ubiquitous object labeling, such as mac_biba(4) and mac_mls(4), and require extensive configuration.

To enable the MAC Framework in your system kernel, you must add the following entry to your kernel configuration:

    options MAC

Security policy modules shipped with the base system may be loaded using kldload(8) or in the boot loader(8) They may also be compiled directly into the kernel using the following options, if the use of modules is not desired.

Different MAC policies may be configured in different ways; frequently, MAC policy modules export configuration parameters using the sysctl(8) MIB using the security.mac namespace. Policies relying on file system or other labels may require a configuration step that involes assigning initial labels to system objects or creating a policy configuration file. For information on how to configure and use each policy module, see its man page.

A variety of tools are available to configure the MAC Framework and labels maintained by various policies. Extensions have been made to the login and credential management mechanisms ( setusercontext(3)) to support initial user labeling using login.conf(5). In addition, modifications have been made to su(1), ps(1), ls(1), and ifconfig(8) to inspect and set labels on processes, files, and interfaces. In addition, several new tools have been added to manage labels on objects, including getfmac(8), setfmac(8), and setfsmac(8) to manage labels on files, and getpmac(8) and setpmac(8).

The Open Web Application Security Project

Linux-Privs

1. Introduction

2. Capabilities

• 2.1 POSIX capabilities

• 2.2 Linux specific capabilities

• 2.3 Other capabilities

3. Capability sets

• 3.1 Sets of capabilities

• 3.2 Filesystem capabilitiy sets

• 3.3 Process/task capabilities

4. Access Control Lists (ACL)

5. Mandatory Access Control (MAC)

6. Information Labels (IL)

7. Sensitivity Labels (SL)

8. Integrity checking; system recovery

9. Auditing

• 9.1 First some kernel infrastructure:

• 9.2 What audit records should contain?

• 9.3 Next some Policy (when/what should we audit):

• 9.4 User level auditing (POSIX):

• 9.5 Internal kernel auditing facility

• 9.6 Preserving the audit log

• 9.7 Auditing policy

10. Process/task credentials

11. Acknowledgements

12. Copyright/license for this document

Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotes :  Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce :  Bernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS :  Programming Languages History : PL/1 : Simula 67 : C : History of GCC development :  Scripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month :  How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: March 12, 2019