||Home||Switchboard||Unix Administration||Red Hat||TCP/IP Networks||Neoliberalism||Toxic Managers|
|(slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and bastardization of classic Unix|
|News||Recommended Links||Principle of Least Privilege||Separation of Duties||MAC in linux||Security Models|
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.
The need for a mandatory access control (MAC) mechanism arises when the security policy of a system dictates that:
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
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:
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.
Mandatory Access Control (MAC), trusted OS features
Reading: Pfleeger, Chap 7
_DoD Trusted Computer System Evaluation Criteria_
* 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)
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
* 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"
to write, C(s) <= C(o)
"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
* "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
UNICOS (Cray UNIX) - early 1990s
Trusted Solaris - late 1990s
* Biba implemented in:
KSOS and KSOS-32
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:
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:
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:
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.
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.
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
3. Capability sets
4. Access Control Lists (ACL)
5. Mandatory Access Control (MAC)
6. Information Labels (IL)
7. Sensitivity Labels (SL)
8. Integrity checking; system recovery
10. Process/task credentials
12. Copyright/license for this document
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
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
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
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
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
Copyright © 1996-2020 by Softpanorama Society. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.
FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.
This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...
|You can use PayPal to to buy a cup of coffee for authors of this site|
Last modified: March 12, 2019