A MAC label is a virtual security stamp which may be applied to subjects and objects throughout the system.
When setting a label, the user must be able to comprehend what it is, exactly, that is being done. Setting the label too high or too low may jeopardize the entire security structure of their directory or file system.
The label specifies exactly what type of access control should be enforced on the object or subject. Formatting of the label is simple, taking the policy name and a qualifier, or setting, for that object or subject.
For instance, setting the label of biba/low on a file will give that file a basic low access control policy.
These labels are what helps to partition, or divide into groups, several objects from each other based on their security profile.
With every policy which supports the labeling feature in FreeBSD, three specific predefined labels are offered, they are the low, high, and equal labels. Although they enforce access control in a different manner with each policy, you can be sure that the low label will be the lowest setting, the equal label will set the subject or object to be disabled or unaffected, and the high label will enforce the highest setting available.
Within single label environments, only one label may be used on objects and subjects. This will enforce one set of access permissions across the entire system and in many environments may be all that is required. There are a few cases; however, where multiple labels may be set on objects or subjects in the system. For those cases, the multilabel option may be passed to tunefs(8).
In other cases still, a numeric label may be set to indicate the precise level of hierarchical control. This numeric compartment is used to partition or sort information into different groups of say, classification only permitting access to that group or a higher group level.
In most cases the administrator will only be setting up a single label to use throughout the file system; indeed this limits the need for the soon to be discussed multilabel option. That option should only be enabled if the situation requires it.
Hey wait, this is similar to DAC! I thought MAC gave control strictly to the administrator. That statement still holds true, root is the one in control and who configures the policy so that users are placed in the appropriate categories/access levels. 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 hierarchal/clearance model discussed earlier in this chapter.
Virtually all aspects of label policy configuration will be performed using a set of four commands. These commands provide a simple interface for object or subject configuration or the manipulation and verification of the configuration.
All configuration may be done by use of the setfmac(8) and setpmac(8) utilities. The setfmac command is used to set MAC labels on system objects while the setpmac command is used to set the labels on system subjects. Observe:
# setfmac biba/high test
If no errors occurred with the command above, a prompt will be returned. The only time these commands are not quiescent is when an error occurred. In some cases this error may be a ``Permission denied'' and is usually obtained when the label is being set or modified on an object which is restricted. 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
As we see above, setpmac can be used to override the policy's
settings by assigning a different label to the invoked process. The getpmac utility is usually used with currently running processes,
such as sendmail: although it takes a process ID in place of a
command the logic is extremely similar. It should be pointed out that users will only be
able to override policy labels if they themselves own the object or subject. If users
attempt to manipulate a file not in their access levels, the ``Operation not permitted'' error will be displayed by the mac_set_link function.
Users themselves are required to have labels so that their files and processes may properly. This is configured through the login.conf file by use of login classes. Every policy that uses labels will enforce the user class setting.
An example entry containing every policy is listed 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/low,lomac10[2]:
The label option is used to set the user class default label which will be enforced by MAC. Users will never be permitted to modify this value, thus it can be considered not optional in the user case. In a real configuration, however, the administrator will never wish to enable every policy. It is recommended that the rest of this chapter be reviewed before any of this configuration is implemented.
In all cases, after a change to login.conf, the login class capability database must be rebuilt using cap_mkdb and this will be reflected throughout every forthcoming example or discussion.
It is useful to note that many sites may have a particularly large number of users requiring several different user classes. In depth planning is required as this may get extremely difficult to manage.
Labels may also be set on network interfaces to help control the flow of data across the network. In all cases they function in the same way the 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.
The 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; otherwise an error will be returned.
Each policy which supports labeling has some 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 from sysctl, the policy manual pages, or even the information found later in this chapter for those tunables.
By default the system will use the singlelabel option. But what does this mean to the administrator? There are several differences which, in their own right, offer pros and cons to the flexibility in the systems security model.
The singlelabel only permits for one label, for instance biba/high to be used for each subject or object. It provides for lower administration overhead but decreases the flexibility of policies which support labeling. Many administrators may want to use the multilabel option in their security policy.
The multilabel option will permit each subject or object to have its own independent MAC label in place of the standard singlelabel option which will allow only one label throughout the partition. The multilabel and single label options are only required for the policies which implement the labeling feature, including the Biba, Lomac, MLS and SEBSD policies.
In many cases, the multilabel may not need to be set at all. 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. Here the file system would not require the multilabel option 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 Biba policy and how it works will be discussed later, so if the previous comment was difficult to interpret just continue reading and return. The server could use a separate partition set at biba/low for most if not all of its runtime state. Much is lacking from this example, for instance the restrictions on data, configuration and user settings; however, this is just a quick example to prove the aforementioned point.
If any of the non-labeling policies are to be used, then the multilabel option would never be required. These include the seeotheruids, portacl and partition policies.
It should also be noted that using multilabel with a partition and establishing a security model based on multilabel functionality could open the doors for higher administrative overhead as everything in the file system would have 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:
# tunefs -l enable /
This is not a requirement for the swap file system.
Note: Some users have experienced problems with setting the multilabel flag on the root partition. If this is the case, please review the Section 11.16 of this chapter.
Without any modules loaded, there are still some parts of MAC which may be configured using the sysctl interface. These tunables are described below and in all cases the number one (1) means enabled while the number zero (0) means disabled:
security.mac.enforce_fs defaults to one (1) and enforces MAC file system policies on the file systems.
security.mac.enforce_kld defaults to one (1) and enforces MAC kernel linking policies on the dynamic kernel linker (see kld(4)).
security.mac.enforce_network defaults to one (1) and enforces MAC network policies.
security.mac.enforce_pipe defaults to one (1) and enforces MAC policies on pipes.
security.mac.enforce_process defaults to one (1) and enforces MAC policies on processes which utilize inter-process communication.
security.mac.enforce_socket defaults to one (1) and enforces MAC policies on sockets (see the socket(2) manual page).
security.mac.enforce_system defaults to one (1) and enforces MAC policies on system activities such as accounting and rebooting.
security.mac.enforce_vm defaults to one (1) and enforces MAC policies on the virtual memory system.
Note: Every policy or MAC option supports tunables. These usually hang off of the security.mac.<policyname> tree. To view all of the tunables from MAC use the following command:
# sysctl -da | grep mac
This should be interpreted as all of the basic MAC policies are enforced by default. If the modules were built into the kernel the system would be extremely locked down and most likely unable to communicate with the local network or connect to the Internet, etc. This is why building the modules into the kernel is not completely recommended. Not because it limits the ability to disable features on the fly with sysctl, but it permits the administrator to instantly switch the policies of a system without the requirement of rebuilding and reinstalling a new system.
This, and other documents, can be downloaded from ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/.
For questions about FreeBSD, read the documentation before contacting <questions@FreeBSD.org>.
For questions about this documentation, e-mail <doc@FreeBSD.org>.