MAC_MLS(4)

💖 MAC_MLS — the Multi-Level Security confidentiality policy, bestie edition 💖

okay so this is the mac_mls manual page, from the Kernel Interfaces Manual, and we're gonna get through it together because it's genuinely iconic. no cap.

---

✨ NAME ✨

mac_mls — the Multi-Level Security confidentiality policy. it's giving "strict information flow" and honestly? obsessed.

---

🎀 SYNOPSIS 🎀

so there are two whole ways to do this. pick your fighter.

Option A: compile MLS straight into your kernel. drop these lines in your kernel configuration file:

options MAC
options MAC_MLS

Option B: load the MLS module at boot time instead. then you only put this in your kernel configuration file:

options MAC

and in loader.conf(5) you add:

mac_mls_load="YES"

periodt. that's the whole synopsis. 🫶

---

💅 DESCRIPTION 💅

so the mac_mls policy module implements the Multi-Level Security model — MLS, for the girlies who abbreviate — and it controls access between subjects and objects based on their confidentiality, by means of a strict information flow policy. every subject and every object in the system has an MLS label attached to it. a subject's MLS label carries its clearance level, and an object's MLS label carries its classification. that's the whole vibe.

in MLS, literally all system subjects and objects get assigned confidentiality labels, and those labels are made up of a sensitivity level plus zero or more compartments. together those label elements let all the labels be placed in a partial order, and the confidentiality protections are based on a dominance operator that describes that order. the sensitivity level is a value between 0 and 65535 — higher values mean higher sensitivity levels, obviously. the compartment field is a set of up to 256 components, numbered from 1 to 256. a complete label has both sensitivity and compartment elements. both. not one or the other.

so with normal labels, dominance is defined as: a label has a higher or equal active sensitivity level, and has at least all of the same compartments as the label it's being compared to. and when we're doing label comparisons:

• “lower” = being dominated by the label it's being compared to
• “higher” = dominating the label it's being compared to
• “equal” = both labels can satisfy the dominance requirements over one another

three special label values exist and they are lowkey the main characters:

(the original page presents this as a little table, and we're keeping every row, don't worry 💖)

the mls/equal label may be applied to subjects and objects for which no enforcement of the MLS security policy is desired. it's the "we're all friends here" label.

the MLS model enforces the following basic restrictions:

• Subjects may not observe the processes of another subject if its clearance level is lower than the clearance level of the object it is attempting to observe.
• Subjects may not read, write, or otherwise observe objects without proper clearance (e.g. subjects may not observe objects whose classification 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 do three things and they are all extremely deliberate: they stop subjects of lower clearance from gaining access to information classified beyond their clearance level, so the confidentiality of classified info is protected. they stop subjects of higher clearance from writing to objects of lower classification, so nobody accidentally or maliciously leaks anything. and they stop subjects of lower clearance from observing subjects of higher clearance at all. 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). slay.

🦋 Label Format 🦋

almost all system objects get tagged with an effective, active label element, reflecting the classification of the object, or the classification of the data contained in the object. in general, object labels look like this:

mls/grade:compartments

for example:

mls/10:2+3+6
mls/low

subject labels are a whole different situation — they consist of three label elements: an effective (active) label, plus a range of available labels. that range is represented using two ordered MLS label elements, and when it's set on a process, it 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 look like this:

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 elements:

rangehigh ≥ effective ≥ rangelow

one class of objects with ranges currently exists, and it's 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. so it's receiving on one label and transmitting within a range. iykyk.

🌸 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 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).

---

💀 IMPLEMENTATION NOTES 💀

ngl, right now 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. so like. noted. 🙈

---

🌈 SEE ALSO 🌈

the whole friend group, fr fr:

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)

---

👑 HISTORY 👑

the mac_mls policy module first appeared in FreeBSD 5.0 and was developed by the TrustedBSD Project. a legend from the very beginning, honestly.

---

🎀 AUTHORS 🎀

this software was contributed to the FreeBSD 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. huge.

---

🍓 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.

read that twice, bestie. it matters. 😭

---

and that's the whole page!! 🦋 this one came from the Debian set of pages, dated July 25, 2015, and the section is MAC_MLS(4) from the Kernel Interfaces Manual. love that for us. mwah 💅✨💖