mac_mls(4)

NAME

mac_mls - Multi-Level Security confidentiality policy

SYNOPSIS

To compile MLS into your kernel, place the  following  lines
in your kernel
configuration file:
      options MAC
      options MAC_MLS
Alternately,  to load the MLS module at boot time, place the
following
line in your kernel configuration file:
      options MAC
and in loader.conf(5):
      mac_mls_load="YES"

DESCRIPTION

The mac_mls policy module implements the Multi-Level Securi

ty, or MLS
model, which controls access between subjects and objects

based on their
confidentiality by means of a strict information flow poli

cy. Each subject and object in the system has an MLS label associated

with it; each
subject's MLS label contains information on its clearance

level, and each
object's MLS label contains information on its classifica

tion.

In MLS, all system subjects and objects are assigned confi

dentiality
labels, made up of a sensitivity level and zero or more com

partments.
Together, these label elements permit all labels to be

placed in a partial order, with confidentiality protections based on a dom

inance operator describing the order. The sensitivity level is ex

pressed as a value
between 0 and 65535, with higher values reflecting higher

sensitivity
levels. The compartment field is expressed as a set of up

to 256 components, numbered from 1 to 256. A complete label consists of

both sensitivity and compartment elements.

With normal labels, dominance is defined as a label having a

higher or
equal active sensitivity level, and having at least all of

the same compartments as the label to which it is being compared. With

respect to
label comparisons, ``lower'' is defined as being dominated

by the label
to which it is being compared, and ``higher'' is defined as

dominating
the label to which it is being compared, and ``equal'' is

defined as both
labels being able to satisfy the dominance requirements over

one another.

Three special label values exist:

Label Comparison
mls/low dominated by all other labels
mls/equal equal to all other labels
mls/high dominates all other labels

The ``mls/equal'' label may be applied to subjects and ob

jects for which
no enforcement of the MLS security policy is desired.

The MLS model enforces the following basic restrictions:

+o Subjects may not observe the processes of another sub

ject if its

clearance level is lower than the clearance level of the

object it is
attempting to observe.

+o Subjects may not read, write, or otherwise observe ob

jects without

proper clearance (e.g. subjects may not observe objects

whose classification label dominates its own clearance label)

+o Subjects may not write to objects with a lower classifi

cation level

than its own clearance level.

+o A subject may read and write to an object if its clear

ance level is

equal to the object's classification level as though MLS

protections
were not in place.

These rules prevent subjects of lower clearance from gaining

access
information classified beyond its clearance level in order

to protect the
confidentiality of classified information, subjects of high

er clearance
from writing to objects of lower classification in order to

prevent the
accidental or malicious leaking of information, and subjects

of lower
clearance from observing subjects of higher clearance alto

gether. In
traditional trusted operating systems, the MLS confidential

ity model is
used in concert with the Biba integrity model (mac_biba(4))

in order to
protect the Trusted Code Base (TCB).

Label Format

Almost all system objects are tagged with an effective, ac

tive label element, reflecting the classification of the object, or clas

sification of
the data contained in the object. In general, object labels

are represented in the following form:

mls/grade:compartments

For example:

mls/10:2+3+6
mls/low

Subject labels consist of three label elements: an effective

(active)
label, as well as a range of available labels. This range

is represented
using two ordered MLS label elements, and when set on a pro

cess, permits
the process to change its active label to any label of

greater or equal
integrity to the low end of the range, and lesser or equal

integrity to
the high end of the range. In general, subject labels are

represented in
the following form:

mls/effectivegrade:effectivecompartments(lograde:locompartmentshigrade:hicompartments)

For example:

mls/10:2+3+6(5:2+3-20:2+3+4+5+6)
mls/high(low-high)

Valid ranged labels must meet the following requirement re

garding their
elements:

rangehigh >= effective >= rangelow

One class of objects with ranges currently exists, the net

work interface.
In the case of the network interface, the effective label

element references the default label for packets received over the inter

face, and the
range represents the range of acceptable labels of packets

to be transmitted over the interface.

Runtime Configuration

The following sysctl(8) MIBs are available for fine-tuning

the enforcement of this MAC policy.

security.mac.mls.enabled Enables the enforcement of

the MLS con

fidentiality policy. (De

fault: 1).

security.mac.mls.ptys_equal Label pty(4)s as

``mls/equal'' upon cre

ation. (Default: 0).

security.mac.mls.revocation_enabled

Revoke access to objects if

the label is
changed to a more sensitive

level than
the subject. (Default: 0).

IMPLEMENTATION NOTES

Currently, the mac_mls policy relies on superuser status

(suser(9)) in
order to change network interface MLS labels. This will

eventually go
away, but it is currently a liability and may allow the su

peruser to
bypass MLS protections.

SEE ALSO

mac(4), mac_biba(4), mac_bsdextended(4), mac_ifoff(4),

mac_lomac(4),
mac_mls(4), mac_none(4), mac_partition(4), mac_portacl(4),
mac_seeotheruids(4), mac_test(4), maclabel(7), mac(9)

HISTORY

The mac_mls policy module first appeared in FreeBSD 5.0 and

was developed
by the TrustedBSD Project.

AUTHORS

This software was contributed to the FreeBSD Project by Net

work Associates Laboratories, the Security Research Division of Network

Associates
Inc. under DARPA/SPAWAR contract N66001-01-C-8035

(``CBOSS''), as part of
the DARPA CHATS research program.

BUGS

See mac(9) concerning appropriateness for production use.

The TrustedBSD
MAC Framework is considered experimental in FreeBSD.

While the MAC Framework design is intended to support the

containment of
the root user, not all attack channels are currently pro

tected by entry
point checks. As such, MAC Framework policies should not be

relied on,
in isolation, to protect against a malicious privileged us

er.

BSD December 1, 2002

BSD