A MAC label is a security attribute which may be applied to subjects and objects throughout the system.
When setting a label, the administrator must be able to comprehend what exactly is being done and understand any implications in order to prevent unexpected or undesired behavior of the system. The attributes available on an object depend on the loaded policy module as policy modules interpret their attributes in different ways.
The security label on an object is used as a part of a security access control decision by a policy. With some policies, the label contains all of the information necessary to make a decision. In other policies, the labels may be processed as part of a larger rule set. For instance, setting the label of biba/low on a file will represent a label maintained by the Biba security policy module, with a value of “low”.
A few policy modules which support the labeling feature in FreeBSD offer three specific predefined labels: low, high, and equal. Such policy modules enforce access control in a different manner with each policy module, where the low label is the lowest setting, the equal label sets the subject or object to be disabled or unaffected, and the high label enforces the highest setting available in the Biba and MLS policy modules.
Within single label file system environments, only one
label may be used on objects. This label enforces one set of
access permissions across the entire system and in many
environments may be all that is required. There are a few
cases where multiple labels may be set on objects or subjects
in the file system by passing multilabel
to
tunefs(8).
In the case of Biba and MLS, a numeric label may be set to indicate the precise level of hierarchical control. This numeric level is used to partition or sort information into different groups of classification only permitting access to that group or a higher group level.
In most cases, the administrator will set up a single label to use throughout the file system. This is similar to DAC to some extent as root is the one in control and who configures the policies so that users are placed in the appropriate categories/access levels. Alas, many policy modules can restrict the root user as well. Basic control over objects will then be released to the group, but root may revoke or modify the settings at any time. This is the hierarchical/clearance model covered by policies such as Biba and MLS.
Virtually all aspects of label policy module configuration will be performed using the base system utilities. These commands provide a simple interface for object or subject configuration or the manipulation and verification of the configuration.
All configuration may be done using setfmac(8) and setpmac(8). setfmac is used to set MAC labels on system objects while setpmac is used to set the labels on system subjects. Observe:
# setfmac biba/high test
If the configuration is successful, the prompt will be returned without error. A common error is “Permission denied” which usually occurs when the label is being set or modified on an object which is restricted.[1] The system administrator may use the following commands to overcome this:
# setfmac biba/high test “Permission denied” # setpmac biba/low setfmac biba/high test # getfmac test test: biba/high
setpmac can be used to override the
policy module's settings by assigning a different label to the
invoked process. getpmac is usually used
with currently running processes, such as
sendmail. It takes a process ID in
place of a command. If users attempt to manipulate a file not
in their access, subject to the rules of the loaded policy
modules, the “Operation not permitted”
error will be displayed by the
mac_set_link
function.
For the mac_biba(4), mac_mls(4) and mac_lomac(4) policy modules, the ability to assign simple labels is provided. These take the form of high, equal, and low, where:
The low label is considered the lowest label setting an object or subject may have. Setting this on objects or subjects blocks their access to objects or subjects marked high.
The equal label should only be placed on objects considered to be exempt from the policy.
The high label grants an object or subject the highest possible setting.
With respect to each policy module, each of those settings will establish a different information flow directive. Refer to the manual pages of the module to determine the traits of these generic label configurations.
Numeric grade labels are used for comparison:compartment+compartment. For example:
biba/10:2+3+6(5:2+3-20:2+3+4+5+6)
may be interpreted as “Biba Policy Label”/“Grade 10”:“Compartments 2, 3 and 6”: (“grade 5 ...”)
In this example, the first grade would be considered the “effective grade” with “effective compartments”, the second grade is the low grade, and the last one is the high grade. In most configurations, these settings will not be used as they are advanced configurations.
System objects only have a current grade/compartment. System subjects reflect the range of available rights in the system, and network interfaces, where they are used for access control.
The grade and compartments in a subject and object pair are used to construct a relationship known as “dominance”, in which a subject dominates an object, the object dominates the subject, neither dominates the other, or both dominate each other. The “both dominate” case occurs when the two labels are equal. Due to the information flow nature of Biba, a user has rights to a set of compartments that might correspond to projects, but objects also have a set of compartments. Users may have to subset their rights using su or setpmac in order to access objects in a compartment from which they are not restricted.
Users are required to have labels so that their files and processes properly interact with the security policy defined on the system. This is configured in login.conf using login classes. Every policy module that uses labels will implement the user class setting.
An example entry containing every policy module setting is displayed below:
default:\ :copyright=/etc/COPYRIGHT:\ :welcome=/etc/motd:\ :setenv=MAIL=/var/mail/$,BLOCKSIZE=K:\ :path=~/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:\ :manpath=/usr/share/man /usr/local/man:\ :nologin=/usr/sbin/nologin:\ :cputime=1h30m:\ :datasize=8M:\ :vmemoryuse=100M:\ :stacksize=2M:\ :memorylocked=4M:\ :memoryuse=8M:\ :filesize=8M:\ :coredumpsize=8M:\ :openfiles=24:\ :maxproc=32:\ :priority=0:\ :requirehome:\ :passwordtime=91d:\ :umask=022:\ :ignoretime@:\ :label=partition/13,mls/5,biba/10(5-15),lomac/10[2]:
To set the
user class default label which will be enforced by
MAC, use label
. Users
are never permitted to modify this value. In a real
configuration, however, the administrator would never enable
every policy module. It is recommended that the rest of
this chapter be reviewed before any configuration is
implemented.
Note: Users may change their label after they login, subject to the constraints of the policy. The example above tells the Biba policy that a process's minimum integrity is 5, its maximum is 15, and the default effective label is 10. The process will run at 10 until it chooses to change label, perhaps due to the user using setpmac(8), which will be constrained by Biba to the configured range.
After any change to login.conf, the login class capability database must be rebuilt using cap_mkdb.
Many sites have a large number of users requiring several different user classes. In depth planning is required as this may get extremely difficult to manage.
Labels may be set on network interfaces to help control the flow of data across the network. Policies using network interface labels function in the same way that policies function with respect to objects. Users at high settings in biba, for example, will not be permitted to access network interfaces with a label of low.
maclabel
may be passed to
ifconfig when setting the
MAC label on network interfaces. For
example:
# ifconfig bge0 maclabel biba/equal
will set the MAC label of biba/equal on the bge(4) interface. When using a setting similar to biba/high(low-high), the entire label should be quoted to prevent an error from being returned.
Each policy module which supports labeling has a tunable
which may be used to disable the MAC
label on network interfaces. Setting the label to
equal
will have a similar effect. Review
the output of sysctl, the policy manual
pages, and the information in this chapter for more
information on those tunables.
By default, the system will use
singlelabel
. For the administrator, there
are several differences which offer pros and cons to the
flexibility in the system's security model.
A security policy which uses singlelabel
only permits one label, such as biba/high,
to be used for each subject or object. This provides lower
administration overhead, but decreases the flexibility of
policies which support labeling.
multilabel
permits each subject or object
to have its own independent MAC label.
The decision to use multilabel
or
singlelabel
is only required for the policies
which implement the labeling feature, including the Biba,
Lomac, and MLS policies.
In many cases, multilabel
may not be
needed. Consider the following situation and security
model:
FreeBSD web-server using the MAC framework and a mix of the various policies.
This machine only requires one label,
biba/high, for everything in the
system. This file system would not require
multilabel
as a single label will always
be in effect.
But, this machine will be a web server and should have the web server run at biba/low to prevent write up capabilities. The server could use a separate partition set at biba/low for most if not all of its runtime state.
If any of the non-labeling policies are to be used,
multilabel
would not be required. These
include the seeotheruids,
portacl and partition
policies.
Using multilabel
with a partition and
establishing a security model based on
multilabel
functionality could increase
administrative overhead as everything in the file system has a
label. This includes directories, files, and even device
nodes.
The following command will set multilabel
on the file systems to have multiple labels. This may only be
done in single user mode and is not a requirement for the swap
file system:
# tunefs -l enable /
Note: Some users have experienced problems with setting the
multilabel
flag on the root partition. If this is the case, please review the Section 17.17 of this chapter.
[1] | Other conditions may produce different failures. For instance, the file may not be owned by the user attempting to relabel the object, the object may not exist, or the object may be read only. A mandatory policy will not allow the process to relabel the file, maybe because of a property of the file, a property of the process, or a property of the proposed new label value. For example, a user running at low integrity tries to change the label of a high integrity file. Or perhaps a user running at low integrity tries to change the label of a low integrity file to a high integrity label. |