| Tests | Recommended Links | MAC in linux | ||||
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)
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.
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
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.