1.\"- 2.\" Copyright (c) 1999-2002 Robert N. M. Watson 3.\" Copyright (c) 2002-2004 Networks Associates Technology, Inc. 4.\" All rights reserved. 5.\" 6.\" This software was developed by Robert Watson for the TrustedBSD Project. 7.\" 8.\" This software was developed for the FreeBSD Project in part by Network 9.\" Associates Laboratories, the Security Research Division of Network 10.\" Associates, Inc. under DARPA/SPAWAR contract N66001-01-C-8035 11.\" ("CBOSS"), as part of the DARPA CHATS research program. 12.\" 13.\" Redistribution and use in source and binary forms, with or without 14.\" modification, are permitted provided that the following conditions 15.\" are met: 16.\" 1. Redistributions of source code must retain the above copyright 17.\" notice, this list of conditions and the following disclaimer. 18.\" 2. Redistributions in binary form must reproduce the above copyright 19.\" notice, this list of conditions and the following disclaimer in the 20.\" documentation and/or other materials provided with the distribution. 21.\" 22.\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND 23.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE 24.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE 25.\" ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE 26.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL 27.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS 28.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) 29.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT 30.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY 31.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF 32.\" SUCH DAMAGE. 33.\" 34.Dd May 20, 2021 35.Dt MAC 9 36.Os 37.Sh NAME 38.Nm mac 39.Nd TrustedBSD Mandatory Access Control framework 40.Sh SYNOPSIS 41.In sys/types.h 42.In sys/mac.h 43.Pp 44In the kernel configuration file: 45.Cd "options MAC" 46.Cd "options MAC_DEBUG" 47.Sh DESCRIPTION 48.Ss Introduction 49The 50.Tn TrustedBSD 51mandatory access control framework permits dynamically 52introduced system security modules to modify system security functionality. 53This can be used to support a variety of new security services, including 54traditional labeled mandatory access control models. 55The framework provides a series of entry points which must be called by 56code supporting various kernel services, especially with respects to access 57control points and object creation. 58The framework then calls out to security modules to offer them the 59opportunity to modify security behavior at those MAC API entry points. 60Both consumers of the API (normal kernel services) and security modules 61must be aware of the semantics of the API calls, particularly with respect 62to synchronization primitives (such as locking). 63.Ss Kernel Objects Supported by the Framework 64The MAC framework manages labels on a variety of types of in-kernel 65objects, including process credentials, vnodes, devfs_dirents, mount 66points, sockets, mbufs, bpf descriptors, network interfaces, IP fragment 67queues, and pipes. 68Label data on kernel objects, represented by 69.Vt "struct label" , 70is policy-unaware, and may be used in the manner seen fit by policy modules. 71.Ss API for Consumers 72The MAC API provides a large set of entry points, too broad to specifically 73document here. 74In general, these entry points represent an access control check or other 75MAC-relevant operations, accept one or more subjects (credentials) 76authorizing the activity, a set of objects on which the operation 77is to be performed, and a set of operation arguments providing information 78about the type of operation being requested. 79.Ss Locking for Consumers 80Consumers of the MAC API must be aware of the locking requirements for 81each API entry point: generally, appropriate locks must be held over each 82subject or object being passed into the call, so that MAC modules may 83make use of various aspects of the object for access control purposes. 84For example, vnode locks are frequently required in order that the MAC 85framework and modules may retrieve security labels and attributes from the 86vnodes for the purposes of access control. 87Similarly, the caller must be aware of the reference counting semantics 88of any subject or object passed into the MAC API: all calls require that 89a valid reference to the object be held for the duration of the 90(potentially lengthy) MAC API call. 91Under some circumstances, objects must be held in either a shared or 92exclusive manner. 93.Ss API for Module Writers 94Each module exports a structure describing the MAC API operations that 95the module chooses to implement, including initialization and destruction 96API entry points, a variety of object creation and destruction calls, 97and a large set of access control check points. 98In the future, additional audit entry points will also be present. 99Module authors may choose to only implement a subset of the entry points, 100setting API function pointers in the description structure to 101.Dv NULL , 102permitting the framework to avoid calling into the module. 103.Ss Locking for Module Writers 104Module writers must be aware of the locking semantics of entry points 105that they implement: MAC API entry points will have specific locking 106or reference counting semantics for each argument, and modules must follow 107the locking and reference counting protocol or risk a variety of failure 108modes (including race conditions, inappropriate pointer dereferences, 109etc). 110.Pp 111MAC module writers must also be aware that MAC API entry points will 112frequently be invoked from deep in a kernel stack, and as such must be 113careful to avoid violating more global locking requirements, such as 114global lock order requirements. 115For example, it may be inappropriate to lock additional objects not 116specifically maintained and ordered by the policy module, or the 117policy module might violate a global ordering requirement relating 118to those additional objects. 119.Pp 120Finally, MAC API module implementors must be careful to avoid 121inappropriately calling back into the MAC framework: the framework 122makes use of locking to prevent inconsistencies during policy module 123attachment and detachment. 124MAC API modules should avoid producing scenarios in which deadlocks 125or inconsistencies might occur. 126.Ss Adding New MAC Entry Points 127The MAC API is intended to be easily expandable as new services are 128added to the kernel. 129In order that policies may be guaranteed the opportunity to ubiquitously 130protect system subjects and objects, it is important that kernel 131developers maintain awareness of when security checks or relevant 132subject or object operations occur in newly written or modified kernel 133code. 134New entry points must be carefully documented so as to prevent any 135confusion regarding lock orders and semantics. 136Introducing new entry points requires four distinct pieces of work: 137introducing new MAC API entries reflecting the operation arguments, 138scattering these MAC API entry points throughout the new or modified 139kernel service, extending the front-end implementation of the MAC API 140framework, and modifying appropriate modules to take advantage of 141the new entry points so that they may consistently enforce their 142policies. 143.Sh ENTRY POINTS 144System service and module authors should reference the 145.%T "FreeBSD Architecture Handbook" 146for information on the MAC Framework APIs. 147.Sh SEE ALSO 148.Xr acl 3 , 149.Xr mac 3 , 150.Xr posix1e 3 , 151.Xr mac 4 , 152.Xr ucred 9 , 153.Xr vaccess 9 , 154.Xr vaccess_acl_posix1e 9 , 155.Xr VFS 9 , 156.Xr VOP_SETLABEL 9 157.Rs 158.%T "The FreeBSD Architecture Handbook" 159.%U "https://docs.freebsd.org/en/books/arch-handbook/" 160.Re 161.Sh HISTORY 162The 163.Tn TrustedBSD 164MAC Framework first appeared in 165.Fx 5.0 . 166.Sh AUTHORS 167This manual page was written by 168.An Robert Watson . 169This software was contributed to the 170.Fx 171Project by Network Associates Laboratories, the Security Research 172Division of Network Associates Inc.\& under DARPA/SPAWAR contract 173N66001-01-C-8035 174.Pq Dq CBOSS , 175as part of the DARPA CHATS research program. 176.Pp 177.An -nosplit 178The 179.Tn TrustedBSD 180MAC Framework was designed by 181.An Robert Watson , 182and implemented by the Network Associates Laboratories Network Security 183(NETSEC), Secure Execution Environment (SEE), and Adaptive 184Network Defense research groups. 185Network Associates Laboratory staff contributing to the CBOSS Project 186include (in alphabetical order): 187.An Lee Badger , 188.An Brian Feldman , 189.An Hrishikesh Dandekar , 190.An Tim Fraser , 191.An Doug Kilpatrick , 192.An Suresh Krishnaswamy , 193.An Adam Migus , 194.An Wayne Morrison , 195.An Andrew Reisse , 196.An Chris Vance , 197and 198.An Robert Watson . 199.Pp 200Sub-contracted staff include: 201.An Chris Costello , 202.An Poul-Henning Kamp , 203.An Jonathan Lemon , 204.An Kirk McKusick , 205.An Dag-Erling Sm\(/orgrav . 206.Pp 207Additional contributors include: 208.An Pawel Dawidek , 209.An Chris Faulhaber , 210.An Ilmar Habibulin , 211.An Mike Halderman , 212.An Bosko Milekic , 213.An Thomas Moestl , 214.An Andrew Reiter , 215and 216.An Tim Robbins . 217.Sh BUGS 218While the MAC Framework design is intended to support the containment of 219the root user, not all attack channels are currently protected by entry 220point checks. 221As such, MAC Framework policies should not be relied on, in isolation, 222to protect against a malicious privileged user. 223