FreeBSD Manual Pages
MAC_MLS(4) Kernel Interfaces Manual MAC_MLS(4) NAME mac_mls -- Multi-Level Security confidentiality policy SYNOPSIS To compile MLS into your kernel, place the following lines in your kernel configuration file: options MAC options MAC_MLS Alternately, to load the MLS module at boot time, place the following line in your kernel configuration file: options MAC and in loader.conf(5): mac_mls_load="YES" DESCRIPTION The mac_mls policy module implements the Multi-Level Security, or MLS model, which controls access between subjects and objects based on their confidentiality by means of a strict information flow policy. Each subject and object in the system has an MLS label associated with it; each sub- ject's MLS label contains information on its clearance level, and each ob- ject's MLS label contains information on its classification. In MLS, all system subjects and objects are assigned confidentiality la- bels, made up of a sensitivity level and zero or more compartments. To- gether, these label elements permit all labels to be placed in a partial order, with confidentiality protections based on a dominance operator de- scribing the order. The sensitivity level is expressed as a value between 0 and 65535, with higher values reflecting higher sensitivity levels. The compartment field is expressed as a set of up to 256 components, numbered from 1 to 256. A complete label consists of both sensitivity and compart- ment elements. With normal labels, dominance is defined as a label having a higher or equal active sensitivity level, and having at least all of the same com- partments as the label to which it is being compared. With respect to la- bel comparisons, "lower" is defined as being dominated by the label to which it is being compared, and "higher" is defined as dominating the label to which it is being compared, and "equal" is defined as both labels being able to satisfy the dominance requirements over one another. Three special label values exist: 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: * Subjects may not observe the processes of another subject if its clear- ance level is lower than the clearance level of the object it is at- tempting to observe. * Subjects may not read, write, or otherwise observe objects without proper clearance (e.g. subjects may not observe objects whose classifi- cation label dominates its own clearance label) * Subjects may not write to objects with a lower classification level than its own clearance level. * A subject may read and write to an object if its clearance level is equal to the object's classification level as though MLS protections were not in place. These rules prevent subjects of lower clearance from gaining access infor- mation classified beyond its clearance level in order to protect the confi- dentiality of classified information, subjects of higher clearance from writing to objects of lower classification in order to prevent the acciden- tal 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 in order to protect the Trusted Code Base (TCB). Label Format Almost all system objects are tagged with an effective, active label ele- ment, 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: mls/grade:compartments For example: mls/10:2+3+6 mls/low Subject labels consist of three label elements: an effective (active) la- bel, as well as a range of available labels. This range is represented us- ing 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 in- tegrity 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: mls/effectivegrade:effectivecompartments(lograde:locompartments- higrade:hicompartments) 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 el- ements: rangehigh >= effective >= rangelow One class of objects with ranges currently exists, the network interface. In the case of the network interface, the effective label element refer- ences the default label for packets received over the interface, and the range represents the range of acceptable labels of packets to be transmit- ted over the interface. Runtime Configuration 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 confiden- tiality 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). IMPLEMENTATION NOTES Currently, the mac_mls policy relies on superuser status (suser(9)) in or- der 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. SEE ALSO mac(4), mac_biba(4), mac_bsdextended(4), mac_ddb(4), mac_ifoff(4), mac_lo- mac(4), mac_none(4), mac_partition(4), mac_portacl(4), mac_seeotheruids(4), mac_test(4), maclabel(7), mac(9) HISTORY The mac_mls policy module first appeared in FreeBSD 5.0 and was developed by the TrustedBSD Project. AUTHORS This software was contributed to the FreeBSD Project by Network Associates Laboratories, the Security Research Division of Network Associates Inc. un- der DARPA/SPAWAR contract N66001-01-C-8035 ("CBOSS"), as part of the DARPA CHATS research program. BUGS 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. FreeBSD ports 15.quarterly July 25, 2015 MAC_MLS(4)
NAME | SYNOPSIS | DESCRIPTION | IMPLEMENTATION NOTES | SEE ALSO | HISTORY | AUTHORS | BUGS
Want to link to this manual page? Use this URL:
<https://man.freebsd.org/cgi/man.cgi?query=mac_mls&manpath=FreeBSD+15.1-RELEASE+and+Ports.quarterly>