1.\"- 2.\" Copyright (c) 1999, 2000, 2001, 2002 Robert N. M. Watson 3.\" Copyright (c) 2002 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 February 16, 2002 37.Os 38.Dt MAC 9 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 TrustedBSD mandatory 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 Note on appropriateness for production use 64The TrustedBSD MAC Framework included in 65.Fx 5.0 66is considered experimental, and should not be deployed in production 67environments without careful consideration of the risks associated with 68the use of experimental operating system features. 69.Ss Kernel objects supported by the framework 70The MAC framework manages labels on a variety of types of in-kernel 71objects, including process credentials, vnodes, devfs_dirents, mount 72points, sockets, mbufs, bpf descriptors, network interfaces, ip fragment 73queues, and pipes. 74Label data on kernel objects, represented by struct label, is 75policy-unaware, and may be used in the manner seen fit by policy modules. 76.Ss API for Consumers 77The MAC API provides a large set of entry points, too broad to specifically 78document here. 79In general, these entry points represent an access control check or other 80MAC-relevant operations, accept one or more subjects (credentials) 81authorizing the activity, a set of objects on which the operation 82is to be performed, and a set of operation arguments providing information 83about the type of operation being requested. 84.Ss Locking for Consumers 85Consumers of the MAC API must be aware of the locking requirements for 86each API entry point: generally, appropriate locks must be held over each 87subject or object being passed into the call, so that MAC modules may 88make use of various aspects of the object for access control purposes. 89For example, vnode locks are frequently required in order that the MAC 90framework and modules may retrieve security labels and attributes from the 91vnodes for the purposes of access control. 92Similarly, the caller must be aware of the reference counting semantics 93of any subject or object passed into the MAC API: all calls require that 94a valid reference to the object be held for the duration of the 95(potentially lengthy) MAC API call. 96Under some circumstances, objects must be held in either a shared or 97exclusive manner. 98.Ss API for Module Writers 99Each module exports a structure describing the MAC API operations that 100the module chooses to implement, including initialization and destruction 101API entry points, a variety of object creation and destruction calls, 102and a large set of access control check points. 103In the future, additional audit entry points will also be present. 104Module authors may choose to only implement a subset of the entry points, 105setting API function pointers in the description structure to NULL, 106permitting the framework to avoid calling into the module. 107.Ss Locking for Module Writers 108Module writers must be aware of the locking semantics of entry points 109that they implement: MAC API entry points will have specific locking 110or reference counting semantics for each argument, and modules must follow 111the locking and reference counting protocol or risk a variety of failure 112modes (including race conditions, inappropriate pointer dereferences, 113etc). 114.Pp 115MAC module writers must also be aware that MAC API entry points will 116frequently be invoked from deep in a kernel stack, and as such must be 117careful to avoid violating more global locking requirements, such as 118global lock order requirements. 119For example, it may be inappropriate to lock additional objects not 120specifically maintained and ordered by the policy module, or the 121policy module might violate a global ordering requirement relating 122to those additional objects. 123.Pp 124Finally, MAC API module implementors must be careful to avoid 125inappropriately calling back into the MAC framework: the framework 126makes use of locking to prevent inconsistencies during policy module 127attachment and detachment. 128MAC API modules should avoid producing scenarios in which deadlocks 129or inconsistencies might occur. 130.Ss Adding New MAC Entry Points 131The MAC API is intended to be easily expandable as new services are 132added to the kernel. 133In order that policies may be guaranteed the opportunity to ubiquitously 134protect system subjects and objects, it is important that kernel 135developers maintain awareness of when security checks or relevant 136subject or object operations occur in newly written or modified kernel 137code. 138New entry points must be carefully documented so as to prevent any 139confusion regarding lock orders and semantics. 140Introducing new entry points requires four distinct pieces of work: 141introducing new MAC API entries reflecting the operation arguments, 142scattering these MAC API entry points throughout the new or modified 143kernel service, extending the front-end implementation of the MAC API 144framework, and modifying appropriate modules to take advantage of 145the new entry points so that they may consistently enforce their 146policies. 147.Sh ENTRY POINTS 148System service and module authors should reference the FreeBSD 149Developer's Handbook for information on the MAC Framework APIs. 150.Pp 151.Sh SEE ALSO 152.Xr acl 3 , 153.Xr cap 3 , 154.Xr mac 3 , 155.Xr lomac 4 , 156.Xr posix1e 3 , 157.Xr ucred 9 , 158.Xr vaccess 9 , 159.Xr vaccess_acl_posix1e 9 , 160.Xr VFS 9 , 161.Sh AUTHORS 162This man page was written by 163.An Robert Watson . 164This software was contributed to the 165.Fx 166Project by Network Associates Laboratories, the Security Research 167Division of Network Associates Inc. under DARPA/SPAWAR contract 168N66001-01-C-8035 ("CBOSS"), as part of the DARPA CHATS research program. 169.Pp 170.An -nosplit 171The TrustedBSD MAC Framework was designed by 172.An Robert Watson , 173and implemented by the Network Associates Laboratories Network Security 174(NETSEC), Secure Execution Environement (SEE), and Adaptive 175Network Defense research groups. 176Network Associates Laboratory staff contributing to the CBOSS Project 177include (in alphabetical order): 178.An Lee Badger , 179.An Brian Feldman , 180.An Tim Fraser , 181.An Doug Kilpatrick , 182.An Suresh Krishnaswamy , 183.An Adam Migus , 184.An Wayne Morrison , 185.An Chris Vance , 186and 187.An Robert Watson . 188.Pp 189Sub-contracted staff include: 190.An Chris Costello , 191.An Poul-Henning Kamp , 192.An Jonathan Lemon , 193.An Kirk McKusick , 194.An Dag-Erling Smorgrav . 195.Pp 196Additional contributors include: 197.An Chris Faulhaber , 198.An Ilmar Habibulin , 199.An Thomas Moestl , 200and 201.An Andrew Reiter . 202.Sh HISTORY 203The TrustedBSD MAC Framework first appeared in 204.Fx 5.0 205.Sh BUGS 206See the earlier section in this document concerning appropriateness 207for production use. 208The TrustedBSD MAC Framework is considered experimental in 209.Fx . 210.Pp 211While the MAC Framework design is intended to support the containment of 212the root user, not all attack channels are current protected by entry 213point checks. 214As such, MAC Framework policies should not be relied on, in isolation, 215to protect against a malicious privileged user. 216