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.\" $FreeBSD$ 35.\" 36.Dd July 25, 2015 37.Dt MAC 9 38.Os 39.Sh NAME 40.Nm mac 41.Nd TrustedBSD Mandatory Access Control framework 42.Sh SYNOPSIS 43.In sys/types.h 44.In sys/mac.h 45.Pp 46In the kernel configuration file: 47.Cd "options MAC" 48.Cd "options MAC_DEBUG" 49.Sh DESCRIPTION 50.Ss Introduction 51The 52.Tn TrustedBSD 53mandatory access control framework permits dynamically 54introduced system security modules to modify system security functionality. 55This can be used to support a variety of new security services, including 56traditional labeled mandatory access control models. 57The framework provides a series of entry points which must be called by 58code supporting various kernel services, especially with respects to access 59control points and object creation. 60The framework then calls out to security modules to offer them the 61opportunity to modify security behavior at those MAC API entry points. 62Both consumers of the API (normal kernel services) and security modules 63must be aware of the semantics of the API calls, particularly with respect 64to synchronization primitives (such as locking). 65.Ss Kernel Objects Supported by the Framework 66The MAC framework manages labels on a variety of types of in-kernel 67objects, including process credentials, vnodes, devfs_dirents, mount 68points, sockets, mbufs, bpf descriptors, network interfaces, IP fragment 69queues, and pipes. 70Label data on kernel objects, represented by 71.Vt "struct label" , 72is policy-unaware, and may be used in the manner seen fit by policy modules. 73.Ss API for Consumers 74The MAC API provides a large set of entry points, too broad to specifically 75document here. 76In general, these entry points represent an access control check or other 77MAC-relevant operations, accept one or more subjects (credentials) 78authorizing the activity, a set of objects on which the operation 79is to be performed, and a set of operation arguments providing information 80about the type of operation being requested. 81.Ss Locking for Consumers 82Consumers of the MAC API must be aware of the locking requirements for 83each API entry point: generally, appropriate locks must be held over each 84subject or object being passed into the call, so that MAC modules may 85make use of various aspects of the object for access control purposes. 86For example, vnode locks are frequently required in order that the MAC 87framework and modules may retrieve security labels and attributes from the 88vnodes for the purposes of access control. 89Similarly, the caller must be aware of the reference counting semantics 90of any subject or object passed into the MAC API: all calls require that 91a valid reference to the object be held for the duration of the 92(potentially lengthy) MAC API call. 93Under some circumstances, objects must be held in either a shared or 94exclusive manner. 95.Ss API for Module Writers 96Each module exports a structure describing the MAC API operations that 97the module chooses to implement, including initialization and destruction 98API entry points, a variety of object creation and destruction calls, 99and a large set of access control check points. 100In the future, additional audit entry points will also be present. 101Module authors may choose to only implement a subset of the entry points, 102setting API function pointers in the description structure to 103.Dv NULL , 104permitting the framework to avoid calling into the module. 105.Ss Locking for Module Writers 106Module writers must be aware of the locking semantics of entry points 107that they implement: MAC API entry points will have specific locking 108or reference counting semantics for each argument, and modules must follow 109the locking and reference counting protocol or risk a variety of failure 110modes (including race conditions, inappropriate pointer dereferences, 111etc). 112.Pp 113MAC module writers must also be aware that MAC API entry points will 114frequently be invoked from deep in a kernel stack, and as such must be 115careful to avoid violating more global locking requirements, such as 116global lock order requirements. 117For example, it may be inappropriate to lock additional objects not 118specifically maintained and ordered by the policy module, or the 119policy module might violate a global ordering requirement relating 120to those additional objects. 121.Pp 122Finally, MAC API module implementors must be careful to avoid 123inappropriately calling back into the MAC framework: the framework 124makes use of locking to prevent inconsistencies during policy module 125attachment and detachment. 126MAC API modules should avoid producing scenarios in which deadlocks 127or inconsistencies might occur. 128.Ss Adding New MAC Entry Points 129The MAC API is intended to be easily expandable as new services are 130added to the kernel. 131In order that policies may be guaranteed the opportunity to ubiquitously 132protect system subjects and objects, it is important that kernel 133developers maintain awareness of when security checks or relevant 134subject or object operations occur in newly written or modified kernel 135code. 136New entry points must be carefully documented so as to prevent any 137confusion regarding lock orders and semantics. 138Introducing new entry points requires four distinct pieces of work: 139introducing new MAC API entries reflecting the operation arguments, 140scattering these MAC API entry points throughout the new or modified 141kernel service, extending the front-end implementation of the MAC API 142framework, and modifying appropriate modules to take advantage of 143the new entry points so that they may consistently enforce their 144policies. 145.Sh ENTRY POINTS 146System service and module authors should reference the 147.%T "FreeBSD Architecture Handbook" 148for information on the MAC Framework APIs. 149.Sh SEE ALSO 150.Xr acl 3 , 151.Xr mac 3 , 152.Xr posix1e 3 , 153.Xr mac_biba 4 , 154.Xr mac_bsdextended 4 , 155.Xr mac_ifoff 4 , 156.Xr mac_lomac 4 , 157.Xr mac_mls 4 , 158.Xr mac_none 4 , 159.Xr mac_partition 4 , 160.Xr mac_seeotheruids 4 , 161.Xr mac_test 4 , 162.Xr ucred 9 , 163.Xr vaccess 9 , 164.Xr vaccess_acl_posix1e 9 , 165.Xr VFS 9 166.Rs 167.%T "The FreeBSD Architecture Handbook" 168.%U "http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/arch-handbook/" 169.Re 170.Sh HISTORY 171The 172.Tn TrustedBSD 173MAC Framework first appeared in 174.Fx 5.0 . 175.Sh AUTHORS 176This manual page was written by 177.An Robert Watson . 178This software was contributed to the 179.Fx 180Project by Network Associates Laboratories, the Security Research 181Division of Network Associates Inc.\& under DARPA/SPAWAR contract 182N66001-01-C-8035 183.Pq Dq CBOSS , 184as part of the DARPA CHATS research program. 185.Pp 186.An -nosplit 187The 188.Tn TrustedBSD 189MAC Framework was designed by 190.An Robert Watson , 191and implemented by the Network Associates Laboratories Network Security 192(NETSEC), Secure Execution Environment (SEE), and Adaptive 193Network Defense research groups. 194Network Associates Laboratory staff contributing to the CBOSS Project 195include (in alphabetical order): 196.An Lee Badger , 197.An Brian Feldman , 198.An Hrishikesh Dandekar , 199.An Tim Fraser , 200.An Doug Kilpatrick , 201.An Suresh Krishnaswamy , 202.An Adam Migus , 203.An Wayne Morrison , 204.An Andrew Reisse , 205.An Chris Vance , 206and 207.An Robert Watson . 208.Pp 209Sub-contracted staff include: 210.An Chris Costello , 211.An Poul-Henning Kamp , 212.An Jonathan Lemon , 213.An Kirk McKusick , 214.An Dag-Erling Sm\(/orgrav . 215.Pp 216Additional contributors include: 217.An Pawel Dawidek , 218.An Chris Faulhaber , 219.An Ilmar Habibulin , 220.An Mike Halderman , 221.An Bosko Milekic , 222.An Thomas Moestl , 223.An Andrew Reiter , 224and 225.An Tim Robbins . 226.Sh BUGS 227While the MAC Framework design is intended to support the containment of 228the root user, not all attack channels are currently protected by entry 229point checks. 230As such, MAC Framework policies should not be relied on, in isolation, 231to protect against a malicious privileged user. 232