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