share/man/man9/mac.9

   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
  44 In the kernel configuration file:
  45 .Cd "options MAC"
  46 .Cd "options MAC_DEBUG"
  47 .Sh DESCRIPTION
  48 .Ss Introduction
  49 The
  50 .Tn TrustedBSD
  51 mandatory access control framework permits dynamically
  52 introduced system security modules to modify system security functionality.
  53 This can be used to support a variety of new security services, including
  54 traditional labeled mandatory access control models.
  55 The framework provides a series of entry points which must be called by
  56 code supporting various kernel services, especially with respects to access
  57 control points and object creation.
  58 The framework then calls out to security modules to offer them the
  59 opportunity to modify security behavior at those MAC API entry points.
  60 Both consumers of the API (normal kernel services) and security modules
  61 must be aware of the semantics of the API calls, particularly with respect
  62 to synchronization primitives (such as locking).
  63 .Ss Kernel Objects Supported by the Framework
  64 The MAC framework manages labels on a variety of types of in-kernel
  65 objects, including process credentials, vnodes, devfs_dirents, mount
  66 points, sockets, mbufs, bpf descriptors, network interfaces, IP fragment
  67 queues, and pipes.
  68 Label data on kernel objects, represented by
  69 .Vt "struct label" ,
  70 is policy-unaware, and may be used in the manner seen fit by policy modules.
  71 .Ss API for Consumers
  72 The MAC API provides a large set of entry points, too broad to specifically
  73 document here.
  74 In general, these entry points represent an access control check or other
  75 MAC-relevant operations, accept one or more subjects (credentials)
  76 authorizing the activity, a set of objects on which the operation
  77 is to be performed, and a set of operation arguments providing information
  78 about the type of operation being requested.
  79 .Ss Locking for Consumers
  80 Consumers of the MAC API must be aware of the locking requirements for
  81 each API entry point: generally, appropriate locks must be held over each
  82 subject or object being passed into the call, so that MAC modules may
  83 make use of various aspects of the object for access control purposes.
  84 For example, vnode locks are frequently required in order that the MAC
  85 framework and modules may retrieve security labels and attributes from the
  86 vnodes for the purposes of access control.
  87 Similarly, the caller must be aware of the reference counting semantics
  88 of any subject or object passed into the MAC API: all calls require that
  89 a valid reference to the object be held for the duration of the
  90 (potentially lengthy) MAC API call.
  91 Under some circumstances, objects must be held in either a shared or
  92 exclusive manner.
  93 .Ss API for Module Writers
  94 Each module exports a structure describing the MAC API operations that
  95 the module chooses to implement, including initialization and destruction
  96 API entry points, a variety of object creation and destruction calls,
  97 and a large set of access control check points.
  98 In the future, additional audit entry points will also be present.
  99 Module authors may choose to only implement a subset of the entry points,
 100 setting API function pointers in the description structure to
 101 .Dv NULL ,
 102 permitting the framework to avoid calling into the module.
 103 .Ss Locking for Module Writers
 104 Module writers must be aware of the locking semantics of entry points
 105 that they implement: MAC API entry points will have specific locking
 106 or reference counting semantics for each argument, and modules must follow
 107 the locking and reference counting protocol or risk a variety of failure
 108 modes (including race conditions, inappropriate pointer dereferences,
 109 etc).
 110 .Pp
 111 MAC module writers must also be aware that MAC API entry points will
 112 frequently be invoked from deep in a kernel stack, and as such must be
 113 careful to avoid violating more global locking requirements, such as
 114 global lock order requirements.
 115 For example, it may be inappropriate to lock additional objects not
 116 specifically maintained and ordered by the policy module, or the
 117 policy module might violate a global ordering requirement relating
 118 to those additional objects.
 119 .Pp
 120 Finally, MAC API module implementors must be careful to avoid
 121 inappropriately calling back into the MAC framework: the framework
 122 makes use of locking to prevent inconsistencies during policy module
 123 attachment and detachment.
 124 MAC API modules should avoid producing scenarios in which deadlocks
 125 or inconsistencies might occur.
 126 .Ss Adding New MAC Entry Points
 127 The MAC API is intended to be easily expandable as new services are
 128 added to the kernel.
 129 In order that policies may be guaranteed the opportunity to ubiquitously
 130 protect system subjects and objects, it is important that kernel
 131 developers maintain awareness of when security checks or relevant
 132 subject or object operations occur in newly written or modified kernel
 133 code.
 134 New entry points must be carefully documented so as to prevent any
 135 confusion regarding lock orders and semantics.
 136 Introducing new entry points requires four distinct pieces of work:
 137 introducing new MAC API entries reflecting the operation arguments,
 138 scattering these MAC API entry points throughout the new or modified
 139 kernel service, extending the front-end implementation of the MAC API
 140 framework, and modifying appropriate modules to take advantage of
 141 the new entry points so that they may consistently enforce their
 142 policies.
 143 .Sh ENTRY POINTS
 144 System service and module authors should reference the
 145 .%T "FreeBSD Architecture Handbook"
 146 for 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
 162 The
 163 .Tn TrustedBSD
 164 MAC Framework first appeared in
 165 .Fx 5.0 .
 166 .Sh AUTHORS
 167 This manual page was written by
 168 .An Robert Watson .
 169 This software was contributed to the
 170 .Fx
 171 Project by Network Associates Laboratories, the Security Research
 172 Division of Network Associates Inc.\& under DARPA/SPAWAR contract
 173 N66001-01-C-8035
 174 .Pq Dq CBOSS ,
 175 as part of the DARPA CHATS research program.
 176 .Pp
 177 .An -nosplit
 178 The
 179 .Tn TrustedBSD
 180 MAC Framework was designed by
 181 .An Robert Watson ,
 182 and implemented by the Network Associates Laboratories Network Security
 183 (NETSEC), Secure Execution Environment (SEE), and Adaptive
 184 Network Defense research groups.
 185 Network Associates Laboratory staff contributing to the CBOSS Project
 186 include (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 ,
 197 and
 198 .An Robert Watson .
 199 .Pp
 200 Sub-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
 207 Additional 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 ,
 215 and
 216 .An Tim Robbins .
 217 .Sh BUGS
 218 While the MAC Framework design is intended to support the containment of
 219 the root user, not all attack channels are currently protected by entry
 220 point checks.
 221 As such, MAC Framework policies should not be relied on, in isolation,
 222 to protect against a malicious privileged user.