Sponsored by DARPA and Network Associates
Laboratories. Contributed by Robert Watson.
FreeBSD 5.0 includes a new kernel security framework, the TrustedBSD MAC Framework.
The MAC Framework permits compile-time, boot-time, and run-time extension of the kernel
access control policy, and can be used to load support for Mandatory Access Control
(MAC), and custom security modules such as hardening
modules. The MAC Framework is currently considered to be an experimental feature, and
should not yet be used in production environments without careful consideration. It is
anticipated that the MAC Framework will be appropriate for more widespread production use
by FreeBSD 5.2.
When configured into a kernel, the MAC Framework permits security modules to augment
the existing kernel access control model, restricting access to system services and
objects. For example, the mac_bsdextended(4)
module augments file system access control, permitting administrators to provide a
firewall-like ruleset constraining access to file system objects based on user ids and
group membership. Some modules require little or no configuration, such as mac_seeotheruids(4),
whereas others perform ubiquitous object labeling, such as mac_biba(4) and mac_mls(4), and
require extensive configuration.
To enable the MAC Framework in your system kernel, you must add the following entry to
your kernel configuration:
options MAC
Security policy modules shipped with the base system may be loaded using kldload(8) or in the
boot loader(8) They may
also be compiled directly into the kernel using the following options, if the use of
modules is not desired.
Different MAC policies may be configured in different ways; frequently, MAC policy
modules export configuration parameters using the sysctl(8) MIB using the security.mac
namespace. Policies relying on file system or other labels may require a configuration
step that involves assigning initial labels to system objects or creating a policy
configuration file. For information on how to configure and use each policy module, see
its manual page.
A variety of tools are available to configure the MAC Framework and labels maintained
by various policies. Extensions have been made to the login and credential management
mechanisms (setusercontext(3)) to
support initial user labeling using login.conf(5). In
addition, modifications have been made to su(1), ps(1), ls(1), and ifconfig(8) to inspect
and set labels on processes, files, and interfaces. In addition, several new tools have
been added to manage labels on objects, including getfmac(8), setfmac(8), and setfsmac(8) to manage
labels on files, and getpmac(8) and setpmac(8).
What follows is a list of policy modules shipped with FreeBSD 5.0.
Vendor: TrustedBSD Project
Module name: mac_biba.ko
Kernel option: MAC_BIBA
The Biba Integrity Policy (mac_biba(4)) provides
for hierarchical and non-hierarchical labeling of all system objects with integrity data,
and the strict enforcement of an information flow policy to prevent corruption of high
integrity subjects and data by low-integrity subjects. Integrity is enforced by
preventing high integrity subjects (generally processes) from reading low integrity
objects (often files), and preventing low integrity subjects from writing to high
integrity objects. This security policy is frequently used in commercial trusted systems
to provide strong protection for the Trusted Code Base (TCB). Because it provides ubiquitous labeling, the Biba
integrity policy must be compiled into the kernel or loaded at boot.
Vendor: TrustedBSD Project
Module name: mac_bsdextended.ko
Kernel option: MAC_BSDEXTENDED
The File System Firewall Policy (mac_bsdextended(4))
provides an extension to the BSD file system permission model, permitting the
administrator to define a set of firewall-like rules for limiting access to file system
objects owned by other users and groups. Managed using ugidfw(8), rules may
limit access to files and directories based on the uid and gids of the process attempting
the access, and the owner and group of the target of the access attempt. All rules are
restrictive, so they may be placed in any order. This policy requires no prior
configuration or labeling, and may be appropriate in multi-user environments where
mandatory limits on inter-user data exchange are required. Caution should be exercised in
limiting access to files owned by the super-user or other system user ids, as many useful
programs and directories are owned by these users. As with a network firewall, improper
application of file system firewall rules may render the system unusable. New tools to
manage the rule set may be easily written using the libugidfw(3)
library.
Vendor: TrustedBSD Project
Module name: mac_ifoff.ko
Kernel option: MAC_IFOFF
The interface silencing policy (mac_ifoff(4))
prohibits the use of network interfaces during the boot until explicitly enabled,
preventing spurious stack output stack response to incoming packets. This is appropriate
for use in environments where the monitoring of packets is required, but no traffic may
be generated.
Vendor: Network Associates Laboratories
Module name: mac_lomac.ko
Kernel option: MAC_LOMAC
Similar to the Biba Integrity Policy, the LOMAC policy (mac_lomac(4)) relies
on the ubiquitous labeling of all system objects with integrity labels. Unlike Biba,
LOMAC permits high integrity subjects to read from low integrity objects, but then
downgrades the label on the subject to prevent future writes to high integrity objects.
This policy may provide for greater compatibility, as well as require less initial
configuration than Biba. However, as with Biba, it ubiquitously labels objects and must
therefore be compiled into the kernel or loaded at boot.
Vendor: TrustedBSD Project
Module name: mac_mls.ko
Kernel option: MAC_MLS
Multi-Level Security (MLS) (mac_mls(4)) provides
for hierarchical and non-hierarchical labeling of all system objects with sensitivity
data, and the strict enforcement of an information flow policy to prevent the leakage of
confidential data to untrusted parties. The logical conjugate of the Biba Integrity
Policy, MLS is frequently shipped in commercial
trusted operating systems to protect data secrecy in multi-user environments. Hierarchal
labels provide support for the notion of clearances and classifications in traditional
parlance; non-hierarchical labels provide support for ``need-to-know.'' As with Biba,
ubiquitous labeling of objects occurs, and it must therefore be compiled into the kernel
or loaded at boot. As with Biba, extensive initial configuration may be required.
Vendor: TrustedBSD Project
Module name: mac_none.ko
Kernel option: MAC_NONE
The None policy (mac_none(4)) provides
a stub sample policy for developers, implementing all entry points, but not changing the
system access control policy. Running this on a production system would not be highly
beneficial.
Vendor: TrustedBSD Project
Module name: mac_partition.ko
Kernel option: MAC_PARTITION
The Partition policy (mac_partition(4))
provides for a simple process visibility limitation, assigning labels to processes
identifying what numeric system partition they are present in. If none, all other
processes are visible using standard monitoring tools; if a partition identifier is
present, then only other processes in the same partition are visible. This policy may be
compiled into the kernel, loaded at boot, or loaded at run-time.
Vendor: TrustedBSD Project
Module name: mac_seeotheruids.ko
Kernel option: MAC_SEEOTHERUIDS
The See Other Uids policy (mac_seeotheruids(4))
implements a similar process visibility model to mac_partition, except that it relies on
process credentials to control visibility of processes, rather than partition labels.
This policy may be configured to exempt certain users and groups, including permitting
system operators to view all processes without special privilege. This policy may be
compiled into the kernel, loaded at boot, or loaded at run-time.
Vendor: TrustedBSD Project
Module name: mac_test.ko
Kernel option: MAC_TEST
The Test policy (mac_test(4)) provides
a regression test environment for the MAC Framework, and will cause a fail-stop in the
event that internal MAC Framework assertions about proper data labeling fail. This module
can be used to detect failures to properly label system objects in the kernel
implementation. This policy may be compiled into the kernel, loaded at boot, or loaded at
run-time.
