Remove the MAC section from this chapter. A chapter has been written to
take its place.
This commit is contained in:
Tom Rhodes
parent
2ccbe3059f
commit
41e081bd3a
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/head/; revision=21214
1 changed files with 1 additions and 264 deletions
|
|
@ -4974,270 +4974,7 @@ user@unfirewalled-system.example.org's password: <userinput>*******</userinput><
|
|||
</sect2>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="mac">
|
||||
<sect1info>
|
||||
<authorgroup>
|
||||
<author>
|
||||
<firstname>Robert</firstname>
|
||||
<surname>Watson</surname>
|
||||
<contrib>Sponsored by DARPA and Network Associates Laboratories.
|
||||
Contributed by </contrib>
|
||||
</author>
|
||||
</authorgroup>
|
||||
</sect1info>
|
||||
<indexterm>
|
||||
<primary>MAC</primary>
|
||||
</indexterm>
|
||||
<title>Mandatory Access Control (MAC)</title>
|
||||
|
||||
<para>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 (<acronym>MAC</acronym>), 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.</para>
|
||||
|
||||
<para>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 &man.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 &man.mac.seeotheruids.4,
|
||||
whereas others perform ubiquitous object labeling, such as
|
||||
&man.mac.biba.4; and &man.mac.mls.4;, and require extensive
|
||||
configuration.</para>
|
||||
|
||||
<para>To enable the MAC Framework in your system kernel, you must
|
||||
add the following entry to your kernel configuration:</para>
|
||||
|
||||
<programlisting>options MAC</programlisting>
|
||||
|
||||
<para>Security policy modules shipped with the base system may
|
||||
be loaded using &man.kldload.8; or in the boot &man.loader.8;
|
||||
They may also be compiled directly into the kernel using the
|
||||
following options, if the use of modules is not desired.</para>
|
||||
|
||||
<para>Different MAC policies may be configured in different ways;
|
||||
frequently, MAC policy modules export configuration parameters
|
||||
using the &man.sysctl.8; <acronym>MIB</acronym> using the
|
||||
<varname>security.mac</varname> 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.</para>
|
||||
|
||||
<para>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
|
||||
(&man.setusercontext.3;) to support initial user labeling using
|
||||
&man.login.conf.5;. In addition, modifications have been made
|
||||
to &man.su.1;, &man.ps.1;, &man.ls.1;, and &man.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 &man.getfmac.8;, &man.setfmac.8;, and
|
||||
&man.setfsmac.8; to manage labels on files, and &man.getpmac.8; and
|
||||
&man.setpmac.8;.</para>
|
||||
|
||||
<para>What follows is a list of policy modules shipped with FreeBSD
|
||||
5.0.</para>
|
||||
<sect2 id="mac-policy-biba">
|
||||
<title>Biba Integrity Policy (mac_biba)</title>
|
||||
<indexterm>
|
||||
<primary>Biba Integrity Policy</primary>
|
||||
</indexterm>
|
||||
<para>Vendor: TrustedBSD Project</para>
|
||||
<para>Module name: mac_biba.ko</para>
|
||||
<para>Kernel option: <literal>MAC_BIBA</literal></para>
|
||||
<indexterm>
|
||||
<primary>TCB</primary>
|
||||
</indexterm>
|
||||
<para>The Biba Integrity Policy (&man.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 (<acronym>TCB</acronym>). Because it
|
||||
provides ubiquitous labeling, the Biba integrity policy
|
||||
must be compiled into the kernel or loaded at boot.</para>
|
||||
</sect2>
|
||||
<sect2 id="mac-policy-bsdextended">
|
||||
<title>File System Firewall Policy (mac_bsdextended)</title>
|
||||
<indexterm>
|
||||
<primary>File System Firewall Policy</primary>
|
||||
</indexterm>
|
||||
<para>Vendor: TrustedBSD Project</para>
|
||||
<para>Module name: mac_bsdextended.ko</para>
|
||||
<para>Kernel option: <literal>MAC_BSDEXTENDED</literal></para>
|
||||
<para> The File System Firewall Policy (&man.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 &man.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 &man.libugidfw.3; library.</para>
|
||||
</sect2>
|
||||
<sect2 id="mac-policy-ifoff">
|
||||
<title>Interface Silencing Policy (mac_ifoff)</title>
|
||||
<indexterm>
|
||||
<primary>Interface Silencing Policy</primary>
|
||||
</indexterm>
|
||||
<para>Vendor: TrustedBSD Project</para>
|
||||
<para>Module name: mac_ifoff.ko</para>
|
||||
<para>Kernel option: <literal>MAC_IFOFF</literal></para>
|
||||
<para>The interface silencing policy (&man.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.</para>
|
||||
</sect2>
|
||||
<sect2 id="mac-policy-lomac">
|
||||
<title>Low-Watermark Mandatory Access Control (LOMAC)
|
||||
(mac_lomac)</title>
|
||||
<indexterm>
|
||||
<primary>MAC</primary>
|
||||
<secondary>Low-Watermark</secondary>
|
||||
</indexterm>
|
||||
<indexterm>
|
||||
<primary>LOMAC</primary>
|
||||
</indexterm>
|
||||
<para>Vendor: Network Associates Laboratories</para>
|
||||
<para>Module name: mac_lomac.ko</para>
|
||||
<para>Kernel option: <literal>MAC_LOMAC</literal></para>
|
||||
<para>Similar to the Biba Integrity Policy, the LOMAC
|
||||
policy (&man.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.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2 id="mac-policy-mls">
|
||||
<title>Multi-Level Security Policy (MLS) (mac_mls)</title>
|
||||
<indexterm>
|
||||
<primary>Multi-Level Security Policy</primary>
|
||||
</indexterm>
|
||||
<indexterm>
|
||||
<primary>MAC</primary>
|
||||
<secondary>Multi-Level</secondary>
|
||||
</indexterm>
|
||||
|
||||
<para>Vendor: TrustedBSD Project</para>
|
||||
<para>Module name: mac_mls.ko</para>
|
||||
<para>Kernel option: <literal>MAC_MLS</literal></para>
|
||||
<para>Multi-Level Security (<acronym>MLS</acronym>)
|
||||
(&man.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,
|
||||
<acronym>MLS</acronym> 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 <quote>need-to-know.</quote> 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.</para>
|
||||
</sect2>
|
||||
<sect2 id="mac-policy-none">
|
||||
<title>MAC Stub Policy (mac_none)</title>
|
||||
<indexterm>
|
||||
<primary>MAC Stub Policy</primary>
|
||||
</indexterm>
|
||||
<para>Vendor: TrustedBSD Project</para>
|
||||
<para>Module name: mac_none.ko</para>
|
||||
<para>Kernel option: <literal>MAC_NONE</literal></para>
|
||||
<para>The None policy (&man.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.</para>
|
||||
</sect2>
|
||||
<sect2 id="mac-policy-partition">
|
||||
<title>Process Partition Policy (mac_partition)</title>
|
||||
<indexterm>
|
||||
<primary>Process Partition Policy</primary>
|
||||
</indexterm>
|
||||
<para>Vendor: TrustedBSD Project</para>
|
||||
<para>Module name: mac_partition.ko</para>
|
||||
<para>Kernel option: <literal>MAC_PARTITION</literal></para>
|
||||
<para>The Partition policy (&man.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.</para>
|
||||
</sect2>
|
||||
<sect2 id="mac-policy-seeotheruids">
|
||||
<title>See Other Uids Policy (mac_seeotheruids)</title>
|
||||
<indexterm>
|
||||
<primary>See Other Uids Policy</primary>
|
||||
</indexterm>
|
||||
<para>Vendor: TrustedBSD Project</para>
|
||||
<para>Module name: mac_seeotheruids.ko</para>
|
||||
<para>Kernel option: <literal>MAC_SEEOTHERUIDS</literal></para>
|
||||
<para>The See Other Uids policy (&man.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.</para>
|
||||
</sect2>
|
||||
<sect2 id="mac-policy-test">
|
||||
<title>MAC Framework Test Policy (mac_test)</title>
|
||||
<indexterm>
|
||||
<primary>MAC Framework Test Policy</primary>
|
||||
</indexterm>
|
||||
<para>Vendor: TrustedBSD Project</para>
|
||||
<para>Module name: mac_test.ko</para>
|
||||
<para>Kernel option: <literal>MAC_TEST</literal></para>
|
||||
<para>The Test policy (&man.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.</para>
|
||||
</sect2>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1 id="fs-acl">
|
||||
<sect1 id="fs-acl">
|
||||
<sect1info>
|
||||
<authorgroup>
|
||||
<author>
|
||||
|
|
|
|||
Loading…
Reference in a new issue