share/man/man4/mac_mls.4

   1 .\" Copyright (c) 2002-2004 Networks Associates Technology, Inc.
   2 .\" All rights reserved.
   3 .\"
   4 .\" This software was developed for the FreeBSD Project by Chris Costello
   5 .\" at Safeport Network Services and Network Associates Laboratories, the
   6 .\" Security Research Division of Network Associates, Inc. under
   7 .\" DARPA/SPAWAR contract N66001-01-C-8035 ("CBOSS"), as part of the
   8 .\" DARPA CHATS research program.
   9 .\"
  10 .\" Redistribution and use in source and binary forms, with or without
  11 .\" modification, are permitted provided that the following conditions
  12 .\" are met:
  13 .\" 1. Redistributions of source code must retain the above copyright
  14 .\"    notice, this list of conditions and the following disclaimer.
  15 .\" 2. Redistributions in binary form must reproduce the above copyright
  16 .\"    notice, this list of conditions and the following disclaimer in the
  17 .\"    documentation and/or other materials provided with the distribution.
  18 .\"
  19 .\" THIS SOFTWARE IS PROVIDED BY THE AUTHORS AND CONTRIBUTORS ``AS IS'' AND
  20 .\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
  21 .\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
  22 .\" ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHORS OR CONTRIBUTORS BE LIABLE
  23 .\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
  24 .\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
  25 .\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
  26 .\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
  27 .\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
  28 .\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
  29 .\" SUCH DAMAGE.
  30 .\"
  31 .\" $FreeBSD$
  32 .\"
  33 .Dd December 1, 2002
  34 .Dt MAC_MLS 4
  35 .Os
  36 .Sh NAME
  37 .Nm mac_mls
  38 .Nd "Multi-Level Security confidentiality policy"
  39 .Sh SYNOPSIS
  40 To compile MLS into your kernel, place the following lines in your kernel
  41 configuration file:
  42 .Bd -ragged -offset indent
  43 .Cd "options MAC"
  44 .Cd "options MAC_MLS"
  45 .Ed
  46 .Pp
  47 Alternately, to load the MLS module at boot time, place the following line
  48 in your kernel configuration file:
  49 .Bd -ragged -offset indent
  50 .Cd "options MAC"
  51 .Ed
  52 .Pp
  53 and in
  54 .Xr loader.conf 5 :
  55 .Bd -literal -offset indent
  56 mac_mls_load="YES"
  57 .Ed
  58 .Sh DESCRIPTION
  59 The
  60 .Nm
  61 policy module implements the Multi-Level Security, or MLS model,
  62 which controls access between subjects and objects based on their
  63 confidentiality by means of a strict information flow policy.
  64 Each subject and object in the system has an MLS label associated with it;
  65 each subject's MLS label contains information on its clearance level,
  66 and each object's MLS label contains information on its classification.
  67 .Pp
  68 In MLS, all system subjects and objects are assigned confidentiality labels,
  69 made up of a sensitivity level and zero or more compartments.
  70 Together, these label elements permit all labels to be placed in a partial
  71 order, with confidentiality protections based on a dominance operator
  72 describing the order.
  73 The sensitivity level is expressed as a value between 0 and
  74 65535, with higher values reflecting higher sensitivity levels.
  75 The compartment field is expressed as a set of up to 256 components,
  76 numbered from 1 to 256.
  77 A complete label consists of both sensitivity and compartment
  78 elements.
  79 .Pp
  80 With normal labels, dominance is defined as a label having a higher
  81 or equal active sensitivity level, and having at least
  82 all of the same compartments as the label to which it is being compared.
  83 With respect to label comparisons,
  84 .Dq Li lower
  85 is defined as being dominated by the label to which it is being compared,
  86 and
  87 .Dq Li higher
  88 is defined as dominating the label to which it is being compared,
  89 and
  90 .Dq Li equal
  91 is defined as both labels being able to satisfy the dominance requirements
  92 over one another.
  93 .Pp
  94 Three special label values exist:
  95 .Bl -column -offset indent ".Li mls/equal" "dominated by all other labels"
  96 .It Sy Label Ta Sy Comparison
  97 .It Li mls/low Ta "dominated by all other labels"
  98 .It Li mls/equal Ta "equal to all other labels"
  99 .It Li mls/high Ta "dominates all other labels"
 100 .El
 101 .Pp
 102 The
 103 .Dq Li mls/equal
 104 label may be applied to subjects and objects for which no enforcement of the
 105 MLS security policy is desired.
 106 .Pp
 107 The MLS model enforces the following basic restrictions:
 108 .Bl -bullet
 109 .It
 110 Subjects may not observe the processes of another subject if its
 111 clearance level is lower than the clearance level of the object it is
 112 attempting to observe.
 113 .It
 114 Subjects may not read, write, or otherwise observe objects without proper
 115 clearance (e.g.\& subjects may not observe objects whose classification label
 116 dominates its own clearance label)
 117 .It
 118 Subjects may not write to objects with a lower classification level than
 119 its own clearance level.
 120 .It
 121 A subject may read and write to an object if its clearance level is equal
 122 to the object's classification level as though MLS protections were not in
 123 place.
 124 .El
 125 .Pp
 126 These rules prevent subjects of lower clearance from gaining access
 127 information classified beyond its clearance level in order to protect the
 128 confidentiality of classified information, subjects of higher clearance
 129 from writing to objects of lower classification in order to prevent the
 130 accidental or malicious leaking of information, and subjects of lower
 131 clearance from observing subjects of higher clearance altogether.
 132 In traditional trusted operating systems, the MLS confidentiality model is
 133 used in concert with the Biba integrity model
 134 .Xr ( mac_biba 4 )
 135 in order to protect the Trusted Code Base (TCB).
 136 .Ss Label Format
 137 Almost all system objects are tagged with an effective, active label element,
 138 reflecting the classification of the object, or classification of the data
 139 contained in the object.
 140 In general, object labels are represented in the following form:
 141 .Pp
 142 .Sm off
 143 .D1 Li mls / Ar grade : compartments
 144 .Sm on
 145 .Pp
 146 For example:
 147 .Bd -literal -offset indent
 148 mls/10:2+3+6
 149 mls/low
 150 .Ed
 151 .Pp
 152 Subject labels consist of three label elements: an effective (active) label,
 153 as well as a range of available labels.
 154 This range is represented using two ordered MLS label elements, and when set
 155 on a process, permits the process to change its active label to any label of
 156 greater or equal integrity to the low end of the range, and lesser or equal
 157 integrity to the high end of the range.
 158 In general, subject labels are represented in the following form:
 159 .Pp
 160 .Sm off
 161 .D1 Li mls / Ar effectivegrade : effectivecompartments ( lograde : locompartments No -
 162 .D1 Ar higrade : hicompartments )
 163 .Sm on
 164 .Pp
 165 For example:
 166 .Bd -literal -offset indent
 167 mls/10:2+3+6(5:2+3-20:2+3+4+5+6)
 168 mls/high(low-high)
 169 .Ed
 170 .Pp
 171 Valid ranged labels must meet the following requirement regarding their
 172 elements:
 173 .Pp
 174 .D1 Ar rangehigh No \[>=] Ar effective No \[>=] Ar rangelow
 175 .Pp
 176 One class of objects with ranges currently exists, the network interface.
 177 In the case of the network interface, the effective label element references
 178 the default label for packets received over the interface, and the range
 179 represents the range of acceptable labels of packets to be transmitted over
 180 the interface.
 181 .Ss Runtime Configuration
 182 The following
 183 .Xr sysctl 8
 184 MIBs are available for fine-tuning the enforcement of this MAC policy.
 185 .Bl -tag -width ".Va security.mac.mls.ptys_equal"
 186 .It Va security.mac.mls.enabled
 187 Enables the enforcement of the MLS confidentiality policy.
 188 (Default: 1).
 189 .It Va security.mac.mls.ptys_equal
 190 Label
 191 .Xr pty 4 Ns s
 192 as
 193 .Dq Li mls/equal
 194 upon creation.
 195 (Default: 0).
 196 .It Va security.mac.mls.revocation_enabled
 197 Revoke access to objects if the label is changed to a more sensitive
 198 level than the subject.
 199 (Default: 0).
 200 .El
 201 .Sh IMPLEMENTATION NOTES
 202 Currently, the
 203 .Nm
 204 policy relies on superuser status
 205 .Pq Xr suser 9
 206 in order to change network interface MLS labels.
 207 This will eventually go away, but it is currently a liability and may
 208 allow the superuser to bypass MLS protections.
 209 .Sh SEE ALSO
 210 .Xr mac 4 ,
 211 .Xr mac_biba 4 ,
 212 .Xr mac_bsdextended 4 ,
 213 .Xr mac_ifoff 4 ,
 214 .Xr mac_lomac 4 ,
 215 .Xr mac_none 4 ,
 216 .Xr mac_partition 4 ,
 217 .Xr mac_portacl 4 ,
 218 .Xr mac_seeotheruids 4 ,
 219 .Xr mac_test 4 ,
 220 .Xr maclabel 7 ,
 221 .Xr mac 9
 222 .Sh HISTORY
 223 The
 224 .Nm
 225 policy module first appeared in
 226 .Fx 5.0
 227 and was developed by the
 228 .Tn TrustedBSD
 229 Project.
 230 .Sh AUTHORS
 231 This software was contributed to the
 232 .Fx
 233 Project by Network Associates Laboratories,
 234 the Security Research Division of Network Associates
 235 Inc.\& under DARPA/SPAWAR contract N66001-01-C-8035
 236 .Pq Dq CBOSS ,
 237 as part of the DARPA CHATS research program.
 238 .Sh BUGS
 239 See
 240 .Xr mac 9
 241 concerning appropriateness for production use.
 242 The
 243 .Tn TrustedBSD
 244 MAC Framework is considered experimental in
 245 .Fx .
 246 .Pp
 247 While the MAC Framework design is intended to support the containment of
 248 the root user, not all attack channels are currently protected by entry
 249 point checks.
 250 As such, MAC Framework policies should not be relied on, in isolation,
 251 to protect against a malicious privileged user.