Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages


home | help
MAC_MLS(4)		 BSD Kernel Interfaces Manual		    MAC_MLS(4)

     mac_mls --	Multi-Level Security confidentiality policy

     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):

     The mac_mls policy	module implements the Multi-Level Security, or MLS
     model, which controls access between subjects and objects based on	their
     confidentiality by	means of a strict information flow policy.  Each sub-
     ject 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 classification.

     In	MLS, all system	subjects and objects are assigned confidentiality la-
     bels, made	up of a	sensitivity level and zero or more compartments.  To-
     gether, these label elements permit all labels to be placed in a partial
     order, with confidentiality protections based on a	dominance operator de-
     scribing the order.  The sensitivity level	is expressed as	a value	be-
     tween 0 and 65535,	with higher values reflecting higher sensitivity lev-
     els.  The compartment field is expressed as a set of up to	256 compo-
     nents, numbered from 1 to 256.  A complete	label consists of both sensi-
     tivity 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 com-
     partments 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 la-
     bel 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 model enforces the	following basic	restrictions:

     o	 Subjects may not observe the processes	of another subject 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 objects without
	 proper	clearance (e.g.	subjects may not observe objects whose classi-
	 fication label	dominates its own clearance label)

     o	 Subjects may not write	to objects with	a lower	classification level
	 than its own clearance	level.

     o	 A subject may read and	write to an object if its clearance 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 in-
     formation classified beyond its clearance level in	order to protect the
     confidentiality of	classified information,	subjects of higher 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 altogether.	In
     traditional trusted operating systems, the	MLS confidentiality 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 a single, active	label element,
     reflecting	the classification of the object, or classification of the
     data contained in the object.  In general,	object labels are represented
     in	the following form:


     For example:


     Subject labels consist of three label elements: a single (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 process,	permits	the
     process to	change its active label	to any label of	greater	or equal in-
     tegrity 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:


     For example:


     Valid ranged labels must meet the following requirement regarding their

	   rangehigh >=	single >= rangelow

     One class of objects with ranges currently	exists,	the network interface.
     In	the case of the	network	interface, the single label element references
     the default label for packets received over the interface,	and the	range
     represents	the range of acceptable	labels of packets to be	transmitted
     over the interface.

     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 superuser to by-
     pass MLS protections.

     mac(4), mac_biba(4), mac_bsdextended(4), mac_ifoff(4), mac_lomac(4),
     mac_mls(4), mac_none(4), mac_partition(4),	mac_seeotheruids(4),
     mac_test(4) maclabel(7), mac(9)

     The mac_mls policy	module first appeared in FreeBSD 5.0 and was developed
     by	the TrustedBSD Project.

     This software was contributed to the FreeBSD Project by Network Asso-
     ciates 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.

     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 protected by entry
     point checks.  As such, MAC Framework policies should not be relied on,
     in	isolation, to protect against a	malicious privileged user.

BSD			       DECEMBER	1, 2002				   BSD


Want to link to this manual page? Use this URL:

home | help