MAC(9)

📦 version 12.2, in debian bookworm, debian trixie, ubuntu jammy, ubuntu noble, ubuntu questing, ubuntu resolute, ubuntu stonking

🌸 MAC(9) 🌸

okay bestie, sit down, hydrate, because we're doing kernel security today 💖 this is the manual page for mac — the TrustedBSD Mandatory Access Control framework — straight outta the Kernel Developer's Manual. it's giving big brain, it's giving kernel dev core, and yes, you're gonna understand it. no cap. ✨

🎀 NAME 🎀

mac — TrustedBSD Mandatory Access Control framework

🦋 SYNOPSIS 🦋

#include <sys/types.h>
#include <sys/mac.h>

and in the kernel configuration file, bestie:

options MAC
options MAC_DEBUG

✨ DESCRIPTION ✨

💅 Introduction 💅

so the TrustedBSD mandatory access control framework lets security modules get dynamically introduced into the system and just... modify how security works. iconic behavior, honestly. and not just one thing either — it can support a whole variety of new security services, including the traditional labeled mandatory access control models. 👑

here's the vibe: the framework provides a series of entry points that have to be called by whatever code is supporting the various kernel services — especially when it comes to access control points and object creation. then the framework calls out to the security modules to offer them the opportunity to modify security behavior at those MAC API entry points. 🫶

and listen: both sides have to be on the same page here. the consumers of the API (that's the normal kernel services) and the security modules must be aware of the semantics of the API calls, particularly with respect to synchronization primitives (such as locking). no one gets to skip that part, it's the whole point. 💀

🌈 Kernel Objects Supported by the Framework 🌈

the MAC framework manages labels on a whole roster of in-kernel object types, and it's a long one, so buckle up:

  • process credentials
  • vnodes
  • devfs_dirents
  • mount points
  • sockets
  • mbufs
  • bpf descriptors
  • network interfaces
  • IP fragment queues
  • pipes

label data on kernel objects is represented by struct label, and it's policy-unaware — meaning it may be used in the manner seen fit by policy modules. it's a blank canvas, a fresh notebook, a brand new aesthetic. 🎨

🍓 API for Consumers 🍓

the MAC API provides a large set of entry points — genuinely too broad to specifically document here, and that's not me being lazy, that's the manual saying it. 😭

but generally? these entry points represent an access control check or other MAC-relevant operations. they accept:

  • one or more subjects (credentials) authorizing the activity,
  • a set of objects on which the operation is to be performed,
  • and a set of operation arguments providing information about the type of operation being requested.

three little categories, doing the absolute most. 💖

🧚 Locking for Consumers 🧚

okay this is the part where you have to actually pay attention, bestie.

consumers of the MAC API must be aware of the locking requirements for each API entry point: generally, appropriate locks must be held over each subject or object being passed into the call, so that MAC modules may make use of various aspects of the object for access control purposes. like — vnode locks are frequently required so that the MAC framework and modules may retrieve security labels and attributes from the vnodes for the purposes of access control.

similarly, the caller must be aware of the reference counting semantics of any subject or object passed into the MAC API: all calls require that a valid reference to the object be held for the duration of the (potentially lengthy) MAC API call. and under some circumstances, objects must be held in either a shared or exclusive manner.

tl;dr — hold the lock, hold the reference, don't fumble the bag. 🔥

🦄 API for Module Writers 🦄

each module exports a structure describing the MAC API operations that the module chooses to implement, and that structure is stacked, fr fr. it includes:

  • initialization and destruction API entry points,
  • a variety of object creation and destruction calls,
  • and a large set of access control check points.

and in the future, additional audit entry points will also be present. 👀

here's the cute part: module authors may choose to only implement a subset of the entry points, setting API function pointers in the description structure to NULL, which lets the framework avoid calling into the module entirely. it's called boundaries and we love her. 🎀

🌸 Locking for Module Writers 🌸

module writers must be aware of the locking semantics of entry points that they implement: MAC API entry points will have specific locking or reference counting semantics for each argument, and modules must follow the locking and reference counting protocol — or risk a variety of failure modes, including race conditions, inappropriate pointer dereferences, etc.

that "etc." is doing a lot of heavy lifting and none of it is good. 💀

MAC module writers must also be aware that MAC API entry points will frequently be invoked from deep in a kernel stack, and as such must be careful to avoid violating more global locking requirements, such as global lock order requirements. for example, it may be inappropriate to lock additional objects not specifically maintained and ordered by the policy module, or the policy module might violate a global ordering requirement relating to those additional objects.

finally, MAC API module implementors must be careful to avoid inappropriately calling back into the MAC framework: the framework makes use of locking to prevent inconsistencies during policy module attachment and detachment. MAC API modules should avoid producing scenarios in which deadlocks or inconsistencies might occur.

no deadlocks. no inconsistencies. we do not do those here. 🚫✨

👑 Adding New MAC Entry Points 👑

the MAC API is intended to be easily expandable as new services are added to the kernel. in order that policies may be guaranteed the opportunity to ubiquitously protect system subjects and objects, it's important that kernel developers maintain awareness of when security checks or relevant subject or object operations occur in newly written or modified kernel code. and new entry points must be carefully documented so as to prevent any confusion regarding lock orders and semantics.

introducing new entry points requires four distinct pieces of work, and I'm listing all four because we don't skip steps in this house:

  1. introducing new MAC API entries reflecting the operation arguments,
  2. scattering these MAC API entry points throughout the new or modified kernel service,
  3. extending the front-end implementation of the MAC API framework,
  4. and modifying appropriate modules to take advantage of the new entry points so that they may consistently enforce their policies.

four steps, all mandatory, no shortcuts. slay. 💅

⭐ ENTRY POINTS ⭐

system service and module authors should reference the FreeBSD Architecture Handbook for information on the MAC Framework APIs. that's the assigned reading, bestie, I don't make the rules. 📚

🔥 SEE ALSO 🔥

The FreeBSD Architecture Handbook, https://www.FreeBSD.org/doc/en_US.ISO8859-1/books/arch-handbook/.

💜 HISTORY 💜

the TrustedBSD MAC Framework first appeared in FreeBSD 5.0. a legend, a pioneer, an origin story. 🫶

🌟 AUTHORS 🌟

this manual page was written by Robert Watson.

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.

the TrustedBSD MAC Framework was designed by Robert Watson, and implemented by the Network Associates Laboratories Network Security (NETSEC), Secure Execution Environment (SEE), and Adaptive Network Defense research groups. Network Associates Laboratory staff contributing to the CBOSS Project include (in alphabetical order):

  • Lee Badger
  • Brian Feldman
  • Hrishikesh Dandekar
  • Tim Fraser
  • Doug Kilpatrick
  • Suresh Krishnaswamy
  • Adam Migus
  • Wayne Morrison
  • Andrew Reisse
  • Chris Vance
  • Robert Watson

sub-contracted staff include:

  • Chris Costello
  • Poul-Henning Kamp
  • Jonathan Lemon
  • Kirk McKusick
  • Dag-Erling Smørgrav

additional contributors include:

  • Pawel Dawidek
  • Chris Faulhaber
  • Ilmar Habibulin
  • Mike Halderman
  • Bosko Milekic
  • Thomas Moestl
  • Andrew Reiter
  • Tim Robbins

a whole group chat of absolute icons, honestly. 🌈

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

bestie, read that one twice. this is a real caveat, not a vibe. 🚨

and that's the whole page, you made it!! 🎉 this one came from the Debian build of the manual, dated July 25, 2015 — go forth and label responsibly, bestie. mwah. 💖✨🎀

📦 where this page comes from