| Label Comparison
mls/low dominated by all other labels
mls/equal equal to all other labels
mls/high dominates all other labels
The "mls/equal" label may be applied to subjects and objects for which no enforcement of the MLS security policy is desired.
The MLS model enforces the following basic restrictions:
These rules prevent subjects of lower clearance from gaining access information classified beyond its clearance level in order to protect the confidentiality of classified information, subjects of higher clearance from writing to objects of lower classification in order to prevent the accidental or malicious leaking of information, and subjects of lower clearance from observing subjects of higher clearance altogether. In traditional trusted operating systems, the MLS confidentiality model is used in concert with the Biba integrity model ( mac_biba 4) in order to protect the Trusted Code Base (TCB).
Almost all system objects are tagged with an effective, active label element, reflecting the classification of the object, or classification of the data contained in the object. In general, object labels are represented in the following form:
For example:mls/10:2+3+6 mls/low
Subject labels consist of three label elements: an effective (active) label, as well as a range of available labels. This range is represented using two ordered MLS label elements, and when set on a process, permits the process to change its active label to any label of greater or equal integrity to the low end of the range, and lesser or equal integrity to the high end of the range. In general, subject labels are represented in the following form:
For example:mls/10:2+3+6(5:2+3-20:2+3+4+5+6) mls/high(low-high)
Valid ranged labels must meet the following requirement regarding their elements:
One class of objects with ranges currently exists, the network interface. In the case of the network interface, the effective label element references the default label for packets received over the interface, and the range represents the range of acceptable labels of packets to be transmitted over the interface.
The following sysctl(8) MIBs are available for fine-tuning the enforcement of this MAC policy.
security.mac.mls.enabled Enables the enforcement of the MLS confidentiality policy. (Default: 1). security.mac.mls.ptys_equal Label pty 4 s as "mls/equal" upon creation. (Default: 0). security.mac.mls.revocation_enabled Revoke access to objects if the label is changed to a more sensitive level than the subject. (Default: 0).
Currently, the mac_mls policy relies on superuser status (suser(9)) in order to change network interface MLS labels. This will eventually go away, but it is currently a liability and may allow the superuser to bypass MLS protections.
mac(4), mac_biba(4), mac_bsdextended(4), mac_ifoff(4), mac_lomac(4), mac_none(4), mac_partition(4), mac_portacl(4), mac_seeotheruids(4), mac_test(4), maclabel(7), mac(9)
The mac_mls policy module first appeared in
.Fx 5.0 and was developed by the TrustedBSD Project.
This software was contributed to the
.Fx Project by Network Associates Laboratories, the Security Research Division of Network Associates Inc. under DARPA/SPAWAR contract N66001-01-C-8035 ("CBOSS"), as part of the DARPA CHATS research program.
While the MAC Framework design is intended to support the containment of the root user, not all attack channels are currently protected by entry point checks. As such, MAC Framework policies should not be relied on, in isolation, to protect against a malicious privileged user.