From owner-p4-projects Thu Mar 6 17:45:54 2003 Delivered-To: p4-projects@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 32767) id AC08537B405; Thu, 6 Mar 2003 17:45:31 -0800 (PST) Delivered-To: perforce@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DE14437B401 for ; Thu, 6 Mar 2003 17:45:29 -0800 (PST) Received: from repoman.freebsd.org (repoman.freebsd.org [216.136.204.115]) by mx1.FreeBSD.org (Postfix) with ESMTP id A800B43F75 for ; Thu, 6 Mar 2003 17:45:28 -0800 (PST) (envelope-from chris@freebsd.org) Received: from repoman.freebsd.org (localhost [127.0.0.1]) by repoman.freebsd.org (8.12.6/8.12.6) with ESMTP id h271jS0U087001 for ; Thu, 6 Mar 2003 17:45:28 -0800 (PST) (envelope-from chris@freebsd.org) Received: (from perforce@localhost) by repoman.freebsd.org (8.12.6/8.12.6/Submit) id h271jSVS086998 for perforce@freebsd.org; Thu, 6 Mar 2003 17:45:28 -0800 (PST) Date: Thu, 6 Mar 2003 17:45:28 -0800 (PST) Message-Id: <200303070145.h271jSVS086998@repoman.freebsd.org> X-Authentication-Warning: repoman.freebsd.org: perforce set sender to chris@freebsd.org using -f From: Chris Costello Subject: PERFORCE change 26458 for review To: Perforce Change Reviews Sender: owner-p4-projects@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG http://perforce.freebsd.org/chv.cgi?CH=26458 Change 26458 by chris@chris_holly on 2003/03/06 17:45:07 Replace the MAC section with a section based on my mac(4) man page. Affected files ... .. //depot/projects/trustedbsd/doc/en_US.ISO8859-1/books/handbook/security/chapter.sgml#14 edit Differences ... ==== //depot/projects/trustedbsd/doc/en_US.ISO8859-1/books/handbook/security/chapter.sgml#14 (text+ko) ==== @@ -3548,258 +3548,561 @@ Robert + Watson + Sponsored by DARPA and Network Associates Laboratories. Contributed by + MAC + Mandatory Access Control (MAC) - 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. + + Legal Notice + + This documentation was developed for the FreeBSD Project + by Chris Costello at Safeport Network Services and 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. + + Redistribution and use in source (SGML DocBook) and + 'compiled' forms (SGML, HTML, PDF, PostScript, RTF and so + forth) with or without modification, are permitted provided + that the following conditions are met: + + + + Redistributions of source code (SGML DocBook) must + retain the above copyright notice, this list of conditions + and the following disclaimer as the first lines of this + file unmodified. + + + + Redistributions in compiled form (transformed to other + DTDs, converted to PDF, PostScript, RTF and other formats) + must reproduce the above copyright notice, this list of + conditions and the following disclaimer in the + documentation and/or other materials provided with the + distribution. + + - 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. + + THIS DOCUMENTATION IS PROVIDED BY THE NETWORKS + ASSOCIATES TECHNOLOGY, INC "AS IS" AND ANY EXPRESS OR + IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A + PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL + NETWORKS ASSOCIATES TECHNOLOGY, INC BE LIABLE FOR ANY + DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR + CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, + PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, + DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED + AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) + ARISING IN ANY WAY OUT OF THE USE OF THIS DOCUMENTATION, + EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + + - To enable the MAC Framework in your system kernel, you must - add the following entry to your kernel configuration: + + Introduction - options MAC + The Mandatory Access Control, or MAC, framework allows + administrators to finely control system security by providing + for a loadable security policy architecture. It is important + to note that due to its nature, MAC security policies may only + restrict access relative to one another and the base system + policy; they cannot override traditional UNIX security + provisions such as file permissions and superuser + checks. - 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. + Each system subject (processes, sockets, etc.) and each + system object (file system objects, sockets, etc.) can carry + with it a MAC label. MAC labels contain data in an arbitrary + format taken into consideration in making access control + decisions for a given operation. Most MAC labels on system + subjects and objects can be modified directly or indirectly by + the system administrator. The format for a given policy's + label may vary depending on the type of object or subject + being labeled. More information on the format for MAC labels + can be found in the &man.maclabel.7; man page. + + + + File System Support - Different MAC policies may be configured in different ways; - frequently, MAC policy modules export configuration parameters - using the &man.sysctl.8; MIB using the - security.mac namespace. Policies relying on - file system or other labels may require a configuration step - that involes 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 man page. + By default, file system enforcement of labeled MAC + policies relies on a single file system label in order to make + access control decisions for all the files in a particular + file system. With some policies, this configuration may not + allow administrators to take full advantage of features. In + order to enable support for labeling files on an individual + basis for a particular file system, the + multilabel flag must be enabled on the file + system. To set the multilabel flag, drop to + single-user mode and unmount the file system, then execute the + following command: - 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;. + &prompt.root; tunefs -l enable filesystem - What follows is a list of policy modules shipped with FreeBSD - 5.0. - - Biba Integrity Policy (mac_biba) - - Biba Integrity Policy - - Vendor: TrustedBSD Project - Module name: mac_biba.ko - Kernel option: MAC_BIBA - - TCB - - 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 (TCB). Because it - provides ubiquitous labeling, the Biba integrity policy - must be compiled into the kernel or loaded at boot. + where filesystem is either the + mount point (in &man.fstab.5;) or the special file (in + /dev) corresponding to the file system on + which to enable multilabel suport. - - File System Firewall Policy (mac_bsdextended) - - File System Firewall Policy - - Vendor: TrustedBSD Project - Module name: mac_bsdextended.ko - Kernel option: MAC_BSDEXTENDED - 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. + + + Policy Enforcement + + MAC can be configured to enforce only specific portions of + policies (see ). Policy + enforcement is divided into the following areas of the + system: + + + + File System + + + File system mounts, modifying directories, modifying + files, etc. + + + + + KLD + + + Loading, unloading, and retrieving statistics on + loaded kernel modules + + + + + Network + + + Network interfaces, &man.bpf.4;, packet delivery and + transmission, interface configuration (&man.ioctl.2;, + &man.ifconfig.8;) + + + + + Pipes + + + Creation of and operation on &man.pipe.2; + objects + + + + + Processes + + + Debugging (e.g. &man.ktrace.2;), process visibility + (&man.ps.1;), process execution (&man.execve.2;), + signalling (&man.kill.2;) + + + + + Sockets + + + Creation of and operation on &man.socket.2; + objects + + + + + System + + + Kernel environment (&man.kenv.1;), system accounting + (&man.acct.2;), &man.reboot.2;, &man.settimeofday.2;, + &man.swapon.2;, &man.sysctl.3;, &man.nfsd.8;-related + operations + + + + + VM + + + &man.mmap.2;-ed files + + + - - Interface Silencing Policy (mac_ifoff) - - Interface Silencing Policy - - Vendor: TrustedBSD Project - Module name: mac_ifoff.ko - Kernel option: MAC_IFOFF - 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. + + + Setting MAC Labels + + From the command line, each type of system object has its + own means for setting and modifying its MAC policy + label. + + + + + + Subject/Object + Utility + + + + + + File system object + &man.setfmac.8;, &man.setfsmac.8; + + + + Network interface + &man.ifconfig.8; + + + + TTY (by login class) + &man.login.conf.5; + + + + User (by login class) + &man.login.conf.5; + + + + + + Additionally, the &man.su.1; and &man.setpmac.8; utilities + can be used to run a command with a different process label + than the shell's current label. - - Low-Watermark Mandatory Access Control (LOMAC) - (mac_lomac) - - Low-Watermark Mandatory Access Control - - - LOMAC - - Vendor: Network Associates Laboratories - Module name: mac_lomac.ko - Kernel option: MAC_LOMAC - 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. + + + Programming with MAC + + MAC security enforcement itself is transparent to + application programs, with the exception that some programs + may need to be aware of additional &man.errno.2; returns from + various system calls. + + The interface for retrieving, handling, and setting policy + labels is documented in the &man.mac.3; man page. - - Multi-Level Security Policy (MLS) (mac_mls) - - Multi-Level Security Policy - - - MLS - - Vendor: TrustedBSD Project - Module name: mac_mls.ko - Kernel option: MAC_MLS - Multi-Level Security (MLS) - (&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, - 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. + + + Runtime Configuration + + The following &man.sysctl.8; MIBs are available for + fine-tuning the enforcement of MAC policies. Unless + specifically noted, all MIBs default to 1 + (that is, all areas are enforced by default): + + + + security.mac.enforce_fs + + + Enforce MAC policies for file system accesses + + + + + security.mac.enforce_kld + + + Enforce MAC policies on &man.kld.4; + + + + + security.mac.enforce_network + + + Enforce MAC policies on network interfaces + + + + + security.mac.enforce_pipe + + + Enforce MAC policies on pipes + + + + + security.mac.enforce_process + + + Enforce MAC policies between system processes + (e.g. &man.ps.1;, &man.ktrace.2;) + + + + + security.mac.enforce_socket + + + Enforce MAC policies on sockets + + + + + security.mac.enforce_system + + + Enfroce MAC policies on system-related items + (e.g. &man.kenv.1;, &man.acct.2;, &man.reboot.2;) + + + - - MAC Stub Policy (mac_none) - - MAC Stub Policy - - Vendor: TrustedBSD Project - Module name: mac_none.ko - Kernel option: MAC_NONE - 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. - - - Process Partition Policy (mac_partition) - - Process Partition Policy - - Vendor: TrustedBSD Project - Module name: mac_partition.ko - Kernel option: MAC_PARTITION - 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. + + + Supported Security Policies + + + What follows is a list of policy modules shipped with FreeBSD + 5.0. + + + Biba Integrity Policy (mac_biba) + + + Biba Integrity Policy + + + Vendor: TrustedBSD Project + Module name: mac_biba.ko + Kernel option: MAC_BIBA + + + TCB + + + 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 + (TCB). Because it provides ubiquitous + labeling, the Biba integrity policy must be compiled into + the kernel or loaded at boot. + + + + File System Firewall Policy (mac_bsdextended) + + + File System Firewall Policy + + + Vendor: TrustedBSD Project + Module name: mac_bsdextended.ko + Kernel option: MAC_BSDEXTENDED + + 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. + + + + Interface Silencing Policy (mac_ifoff) + + + Interface Silencing Policy + + + Vendor: TrustedBSD Project + Module name: mac_ifoff.ko + Kernel option: MAC_IFOFF + + 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. + + + + Low-Watermark Mandatory Access Control (LOMAC) + (mac_lomac) + + + Low-Watermark Mandatory Access Control + + + + LOMAC + + + Vendor: Network Associates Laboratories + Module name: mac_lomac.ko + Kernel option: MAC_LOMAC + + 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. + + + + Multi-Level Security Policy (MLS) (mac_mls) + + Multi-Level Security Policy + + + MLS + + Vendor: TrustedBSD Project + Module name: mac_mls.ko + Kernel option: MAC_MLS + + Multi-Level Security (MLS) + (&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, + 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. + + + + MAC Stub Policy (mac_none) + + + MAC Stub Policy + + + Vendor: TrustedBSD Project + Module name: mac_none.ko + Kernel option: MAC_NONE + + 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. + + + + Process Partition Policy (mac_partition) + + + Process Partition Policy + + + Vendor: TrustedBSD Project + Module name: mac_partition.ko + Kernel option: MAC_PARTITION + + 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. + + + + See Other Uids Policy (mac_seeotheruids) + + + See Other Uids Policy + + + Vendor: TrustedBSD Project + Module name: mac_seeotheruids.ko + Kernel option: + MAC_SEEOTHERUIDS + + 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. + + + + MAC Framework Test Policy (mac_test) + + + MAC Framework Test Policy + + + Vendor: TrustedBSD Project + Module name: mac_test.ko + Kernel option: MAC_TEST + + 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. + - - See Other Uids Policy (mac_seeotheruids) - - See Other Uids Policy - - Vendor: TrustedBSD Project - Module name: mac_seeotheruids.ko - Kernel option: MAC_SEEOTHERUIDS - 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. - - - MAC Framework Test Policy (mac_test) - - MAC Framework Test Policy - - Vendor: TrustedBSD Project - Module name: mac_test.ko - Kernel option: MAC_TEST - 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. - - To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe p4-projects" in the body of the message