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