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