*nix Documentation Project
·  Home
 +   man pages
·  Linux HOWTOs
·  FreeBSD Tips
·  *niX Forums

  man pages->FreeBSD man pages -> mac_mls (4)              



NAME    [Toc]    [Back]

     mac_mls -- Multi-Level Security confidentiality policy

SYNOPSIS    [Toc]    [Back]

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


DESCRIPTION    [Toc]    [Back]

     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 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 classification.

     In MLS, all system subjects and objects are assigned confidentiality
     labels, made up of a sensitivity level and zero or more compartments.
     Together, these label elements permit all labels to be placed in a partial
 order, with confidentiality protections based on a dominance operator
 describing the order.	The sensitivity level is expressed 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 objects 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 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 classification
 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
     information 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    [Toc]    [Back]
     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
     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:


     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.

   Runtime Configuration    [Toc]    [Back]
     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 confidentiality
 policy.  (Default: 1).

     security.mac.mls.ptys_equal  Label pty(4)s as ``mls/equal'' upon creation.
  (Default: 0).

				  Revoke access to objects if the label is
				  changed to a more sensitive level than the
				  subject.  (Default: 0).


     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
     bypass MLS protections.

SEE ALSO    [Toc]    [Back]

     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    [Toc]    [Back]

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

AUTHORS    [Toc]    [Back]

     This software was contributed to the FreeBSD Project by Network 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    [Toc]    [Back]

     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.

FreeBSD 5.2.1		       December 1, 2002 		 FreeBSD 5.2.1
[ Back ]
 Similar pages
Name OS Title
t6ext_attr IRIX Activate extended security attributes or set policy on security attribute change
hunt NetBSD a multi-player multi-terminal game
hunt OpenBSD a multi-player multi-terminal game
siad_test_newpass Tru64 test passphrase against rules and policy routine for SIA (Security Integration Architecture)
ftn_mpio IRIX Fortran Multi-Threaded I/O
locale Linux Description of multi-language support
iflMT IRIX a multi-track movie file
mekton IRIX multi-player networked game
sail NetBSD multi-user wooden ships and iron men
pthread_multi_np FreeBSD switch between multi- and singlethreaded scheduling modes
Copyright © 2004-2005 DeniX Solutions SRL
newsletter delivery service