xref: /freebsd/share/man/man4/mac_mls.4 (revision 61ba55bcf70f2340f9c943c9571113b3fd8eda69)
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.Dd July 25, 2015
32.Dt MAC_MLS 4
33.Os
34.Sh NAME
35.Nm mac_mls
36.Nd "Multi-Level Security confidentiality policy"
37.Sh SYNOPSIS
38To compile MLS into your kernel, place the following lines in your kernel
39configuration file:
40.Bd -ragged -offset indent
41.Cd "options MAC"
42.Cd "options MAC_MLS"
43.Ed
44.Pp
45Alternately, to load the MLS module at boot time, place the following line
46in your kernel configuration file:
47.Bd -ragged -offset indent
48.Cd "options MAC"
49.Ed
50.Pp
51and in
52.Xr loader.conf 5 :
53.Bd -literal -offset indent
54mac_mls_load="YES"
55.Ed
56.Sh DESCRIPTION
57The
58.Nm
59policy module implements the Multi-Level Security, or MLS model,
60which controls access between subjects and objects based on their
61confidentiality by means of a strict information flow policy.
62Each subject and object in the system has an MLS label associated with it;
63each subject's MLS label contains information on its clearance level,
64and each object's MLS label contains information on its classification.
65.Pp
66In MLS, all system subjects and objects are assigned confidentiality labels,
67made up of a sensitivity level and zero or more compartments.
68Together, these label elements permit all labels to be placed in a partial
69order, with confidentiality protections based on a dominance operator
70describing the order.
71The sensitivity level is expressed as a value between 0 and
7265535, with higher values reflecting higher sensitivity levels.
73The compartment field is expressed as a set of up to 256 components,
74numbered from 1 to 256.
75A complete label consists of both sensitivity and compartment
76elements.
77.Pp
78With normal labels, dominance is defined as a label having a higher
79or equal active sensitivity level, and having at least
80all of the same compartments as the label to which it is being compared.
81With respect to label comparisons,
82.Dq Li lower
83is defined as being dominated by the label to which it is being compared,
84and
85.Dq Li higher
86is defined as dominating the label to which it is being compared,
87and
88.Dq Li equal
89is defined as both labels being able to satisfy the dominance requirements
90over one another.
91.Pp
92Three special label values exist:
93.Bl -column -offset indent ".Li mls/equal" "dominated by all other labels"
94.It Sy Label Ta Sy Comparison
95.It Li mls/low Ta "dominated by all other labels"
96.It Li mls/equal Ta "equal to all other labels"
97.It Li mls/high Ta "dominates all other labels"
98.El
99.Pp
100The
101.Dq Li mls/equal
102label may be applied to subjects and objects for which no enforcement of the
103MLS security policy is desired.
104.Pp
105The MLS model enforces the following basic restrictions:
106.Bl -bullet
107.It
108Subjects may not observe the processes of another subject if its
109clearance level is lower than the clearance level of the object it is
110attempting to observe.
111.It
112Subjects may not read, write, or otherwise observe objects without proper
113clearance (e.g.\& subjects may not observe objects whose classification label
114dominates its own clearance label)
115.It
116Subjects may not write to objects with a lower classification level than
117its own clearance level.
118.It
119A subject may read and write to an object if its clearance level is equal
120to the object's classification level as though MLS protections were not in
121place.
122.El
123.Pp
124These rules prevent subjects of lower clearance from gaining access
125information classified beyond its clearance level in order to protect the
126confidentiality of classified information, subjects of higher clearance
127from writing to objects of lower classification in order to prevent the
128accidental or malicious leaking of information, and subjects of lower
129clearance from observing subjects of higher clearance altogether.
130In traditional trusted operating systems, the MLS confidentiality model is
131used in concert with the Biba integrity model
132.Xr ( mac_biba 4 )
133in order to protect the Trusted Code Base (TCB).
134.Ss Label Format
135Almost all system objects are tagged with an effective, active label element,
136reflecting the classification of the object, or classification of the data
137contained in the object.
138In general, object labels are represented in the following form:
139.Pp
140.Sm off
141.D1 Li mls / Ar grade : compartments
142.Sm on
143.Pp
144For example:
145.Bd -literal -offset indent
146mls/10:2+3+6
147mls/low
148.Ed
149.Pp
150Subject labels consist of three label elements: an effective (active) label,
151as well as a range of available labels.
152This range is represented using two ordered MLS label elements, and when set
153on a process, permits the process to change its active label to any label of
154greater or equal integrity to the low end of the range, and lesser or equal
155integrity to the high end of the range.
156In general, subject labels are represented in the following form:
157.Pp
158.Sm off
159.D1 Li mls / Ar effectivegrade : effectivecompartments ( lograde : locompartments No -
160.D1 Ar higrade : hicompartments )
161.Sm on
162.Pp
163For example:
164.Bd -literal -offset indent
165mls/10:2+3+6(5:2+3-20:2+3+4+5+6)
166mls/high(low-high)
167.Ed
168.Pp
169Valid ranged labels must meet the following requirement regarding their
170elements:
171.Pp
172.D1 Ar rangehigh No \[>=] Ar effective No \[>=] Ar rangelow
173.Pp
174One class of objects with ranges currently exists, the network interface.
175In the case of the network interface, the effective label element references
176the default label for packets received over the interface, and the range
177represents the range of acceptable labels of packets to be transmitted over
178the interface.
179.Ss Runtime Configuration
180The following
181.Xr sysctl 8
182MIBs are available for fine-tuning the enforcement of this MAC policy.
183.Bl -tag -width ".Va security.mac.mls.ptys_equal"
184.It Va security.mac.mls.enabled
185Enables the enforcement of the MLS confidentiality policy.
186(Default: 1).
187.It Va security.mac.mls.ptys_equal
188Label
189.Xr pty 4 Ns s
190as
191.Dq Li mls/equal
192upon creation.
193(Default: 0).
194.It Va security.mac.mls.revocation_enabled
195Revoke access to objects if the label is changed to a more sensitive
196level than the subject.
197(Default: 0).
198.El
199.Sh IMPLEMENTATION NOTES
200Currently, the
201.Nm
202policy relies on superuser status
203.Pq Xr suser 9
204in order to change network interface MLS labels.
205This will eventually go away, but it is currently a liability and may
206allow the superuser to bypass MLS protections.
207.Sh SEE ALSO
208.Xr mac 4 ,
209.Xr mac_biba 4 ,
210.Xr mac_bsdextended 4 ,
211.Xr mac_ddb 4 ,
212.Xr mac_ifoff 4 ,
213.Xr mac_lomac 4 ,
214.Xr mac_none 4 ,
215.Xr mac_partition 4 ,
216.Xr mac_portacl 4 ,
217.Xr mac_seeotheruids 4 ,
218.Xr mac_test 4 ,
219.Xr maclabel 7 ,
220.Xr mac 9
221.Sh HISTORY
222The
223.Nm
224policy module first appeared in
225.Fx 5.0
226and was developed by the
227.Tn TrustedBSD
228Project.
229.Sh AUTHORS
230This software was contributed to the
231.Fx
232Project by Network Associates Laboratories,
233the Security Research Division of Network Associates
234Inc.\& under DARPA/SPAWAR contract N66001-01-C-8035
235.Pq Dq CBOSS ,
236as part of the DARPA CHATS research program.
237.Sh BUGS
238While the MAC Framework design is intended to support the containment of
239the root user, not all attack channels are currently protected by entry
240point checks.
241As such, MAC Framework policies should not be relied on, in isolation,
242to protect against a malicious privileged user.
243