From owner-svn-doc-all@FreeBSD.ORG Fri Mar 28 16:58:45 2014 Return-Path: Delivered-To: svn-doc-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DCCF9F9C; Fri, 28 Mar 2014 16:58:45 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C86EB67B; Fri, 28 Mar 2014 16:58:45 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s2SGwjtc073549; Fri, 28 Mar 2014 16:58:45 GMT (envelope-from dru@svn.freebsd.org) Received: (from dru@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s2SGwj5L073548; Fri, 28 Mar 2014 16:58:45 GMT (envelope-from dru@svn.freebsd.org) Message-Id: <201403281658.s2SGwj5L073548@svn.freebsd.org> From: Dru Lavigne Date: Fri, 28 Mar 2014 16:58:45 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r44375 - head/en_US.ISO8859-1/books/handbook/mac X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-all@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "SVN commit messages for the entire doc trees \(except for " user" , " projects" , and " translations" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2014 16:58:45 -0000 Author: dru Date: Fri Mar 28 16:58:45 2014 New Revision: 44375 URL: http://svnweb.freebsd.org/changeset/doc/44375 Log: White space fix only. Translators can ignore. Sponsored by: iXsystems Modified: head/en_US.ISO8859-1/books/handbook/mac/chapter.xml Modified: head/en_US.ISO8859-1/books/handbook/mac/chapter.xml ============================================================================== --- head/en_US.ISO8859-1/books/handbook/mac/chapter.xml Fri Mar 28 15:55:53 2014 (r44374) +++ head/en_US.ISO8859-1/books/handbook/mac/chapter.xml Fri Mar 28 16:58:45 2014 (r44375) @@ -552,10 +552,10 @@ test: biba/high Planning the Security Configuration - Before implementing any MAC policies, a planning phase - is recommended. During the planning stages, an administrator - should consider the implementation requirements and - goals, such as: + Before implementing any MAC policies, a + planning phase is recommended. During the planning stages, an + administrator should consider the implementation requirements + and goals, such as: @@ -570,32 +570,30 @@ test: biba/high - Which MAC modules will be - required to achieve this goal. + Which MAC modules will be required to + achieve this goal. - A trial run of the trusted - system and its configuration should occur - before a MAC - implementation is used on production systems. Since different - environments have different needs and - requirements, establishing a complete security - profile will decrease the need of changes once the system - goes live. - - Consider how the - MAC framework augments the security of - the system as a whole. The various security policy modules - provided by the MAC framework could be used - to protect the network and file systems or to block users from - accessing certain ports and sockets. Perhaps the best use of - the policy modules is to load several security policy modules at - a time in order to provide a MLS environment. - This approach differs from a hardening policy, which typically - hardens elements of a system which are used only for specific - purposes. The downside to MLS is increased - administrative overhead. + A trial run of the trusted system and its configuration + should occur before a + MAC implementation is used on production + systems. Since different environments have different needs and + requirements, establishing a complete security profile will + decrease the need of changes once the system goes live. + + Consider how the MAC framework augments + the security of the system as a whole. The various security + policy modules provided by the MAC framework + could be used to protect the network and file systems or to + block users from accessing certain ports and sockets. Perhaps + the best use of the policy modules is to load several security + policy modules at a time in order to provide a + MLS environment. This approach differs from + a hardening policy, which typically hardens elements of a system + which are used only for specific purposes. The downside to + MLS is increased administrative + overhead. The overhead is minimal when compared to the lasting effect of a framework which provides the ability to pick and choose @@ -615,10 +613,10 @@ test: biba/high MAC access rules is in the hands of the system administrator. - It is the duty of the system administrator to - carefully select the correct security policy modules. For an - environment that needs to limit access control over the network, - the &man.mac.portacl.4;, &man.mac.ifoff.4;, and &man.mac.biba.4; + It is the duty of the system administrator to carefully + select the correct security policy modules. For an environment + that needs to limit access control over the network, the + &man.mac.portacl.4;, &man.mac.ifoff.4;, and &man.mac.biba.4; policy modules make good starting points. For an environment where strict confidentiality of file system objects is required, consider the &man.mac.bsdextended.4; and &man.mac.mls.4; policy @@ -646,17 +644,17 @@ test: biba/high framework will help administrators choose the best policies for their situations. - The rest of this chapter covers the available - modules, describes their use and configuration, and in some - cases, provides insight on applicable situations. + The rest of this chapter covers the available modules, + describes their use and configuration, and in some cases, + provides insight on applicable situations. Implementing MAC is much like - implementing a firewall since care must be taken to prevent being - completely locked out of the system. The ability to revert - back to a previous configuration should be considered and the - implementation of MAC over a remote connection should be - done with extreme caution. + implementing a firewall since care must be taken to prevent + being completely locked out of the system. The ability to + revert back to a previous configuration should be considered + and the implementation of MAC over a remote + connection should be done with extreme caution. @@ -664,14 +662,14 @@ test: biba/high Available MAC Policies Beginning with &os; 8.0, the default &os; kernel - includes options MAC. This means that - every module included with the MAC - framework can be loaded with kldload as a run-time kernel module. - After testing the module, add the module name to + includes options MAC. This means that every + module included with the MAC framework can be + loaded with kldload as a run-time kernel + module. After testing the module, add the module name to /boot/loader.conf so that it will load - during boot. Each module also provides a kernel option - for those administrators who choose to compile their own - custom kernel. + during boot. Each module also provides a kernel option for + those administrators who choose to compile their own custom + kernel. &os; includes a group of policies that will cover most security requirements. Each policy is summarized below. The @@ -693,8 +691,8 @@ test: biba/high Boot option: mac_seeotheruids_load="YES" - The &man.mac.seeotheruids.4; module extends - the security.bsd.see_other_uids and + The &man.mac.seeotheruids.4; module extends the + security.bsd.see_other_uids and security.bsd.see_other_gids sysctl tunables. This option does not require any labels to be set before configuration and can @@ -707,9 +705,9 @@ test: biba/high security.mac.seeotheruids.enabled - enables the module and implements the default settings which - deny users the ability to view processes and sockets owned - by other users. + enables the module and implements the default settings + which deny users the ability to view processes and sockets + owned by other users. @@ -750,15 +748,14 @@ test: biba/high Boot option: mac_bsdextended_load="YES" - The &man.mac.bsdextended.4; module enforces a file - system firewall. It provides an extension - to the standard file system permissions model, permitting an - administrator to create a firewall-like ruleset to protect - files, utilities, and directories in the file system - hierarchy. When access to a file system object is attempted, - the list of rules is iterated until either a matching rule is - located or the end is reached. This behavior may be changed - using + The &man.mac.bsdextended.4; module enforces a file system + firewall. It provides an extension to the standard file + system permissions model, permitting an administrator to + create a firewall-like ruleset to protect files, utilities, + and directories in the file system hierarchy. When access to + a file system object is attempted, the list of rules is + iterated until either a matching rule is located or the end is + reached. This behavior may be changed using security.mac.bsdextended.firstmatch_enabled. Similar to other firewall modules in &os;, a file containing the access control rules can be created and read by the system @@ -769,41 +766,43 @@ test: biba/high written by using the functions in the &man.libugidfw.3; library. - After the &man.mac.bsdextended.4; module has been - loaded, the following command may be used to list the - current rule configuration: + After the &man.mac.bsdextended.4; module has been loaded, + the following command may be used to list the current rule + configuration: - &prompt.root; ugidfw list + &prompt.root; ugidfw list 0 slots, 0 rules - By default, no rules are defined and everything is - completely accessible. To create a rule which blocks - all access by users but leaves root unaffected: - - &prompt.root; ugidfw add subject not uid root new object not uid root mode n - - While this rule is simple to implement, it is a very bad idea as it blocks all users from - issuing any commands. A more realistic example blocks - user1 all - access, including directory listings, to user2's - home directory: + By default, no rules are defined and everything is + completely accessible. To create a rule which blocks all + access by users but leaves root unaffected: + + &prompt.root; ugidfw add subject not uid root new object not uid root mode n + + While this rule is simple to implement, it is a very bad + idea as it blocks all users from issuing any commands. A + more realistic example blocks user1 all access, including + directory listings, to user2's + home directory: &prompt.root; ugidfw set 2 subject uid user1 object uid user2 mode n &prompt.root; ugidfw set 3 subject uid user1 object gid user2 mode n - Instead of user1, could be - used in order to enforce the same access restrictions for all - users. However, the root - user is unaffected by these rules. - - - Extreme caution should be taken when working with this - module as incorrect use could block access to certain parts of - the file system. + Instead of user1, could be used + in order to enforce the same access restrictions for all + users. However, the root user is unaffected by + these rules. + + + Extreme caution should be taken when working with this + module as incorrect use could block access to certain + parts of the file system. @@ -821,10 +820,10 @@ test: biba/high Boot option: mac_ifoff_load="YES" - The &man.mac.ifoff.4; module is used to disable - network interfaces on the fly and to keep network interfaces from - being brought up during system boot. It does not use - labels and does not depend on any other + The &man.mac.ifoff.4; module is used to disable network + interfaces on the fly and to keep network interfaces from + being brought up during system boot. It does not use labels + and does not depend on any other MAC modules. Most of this module's control is performed through these @@ -853,8 +852,8 @@ test: biba/high One of the most common uses of &man.mac.ifoff.4; is network monitoring in an environment where network traffic should not be permitted during the boot sequence. Another - use would be to write a script which uses an application such as - security/aide to automatically block + use would be to write a script which uses an application such + as security/aide to automatically block network traffic if it finds new or altered files in protected directories. @@ -904,19 +903,18 @@ test: biba/high security.mac.portacl.rules - specifies the policy as a text string - of the form rule[,rule,...], with as - many rules as needed, and where each rule is of the form + specifies the policy as a text string of the form + rule[,rule,...], with as many rules as + needed, and where each rule is of the form idtype:id:protocol:port. The idtype is either uid or gid. The protocol parameter can be - tcp or - udp. The + tcp or udp. The port parameter is the port number to allow the specified user or group to bind to. Only numeric values can be used for the user ID, group ID, - and port parameters. + and port parameters. @@ -931,27 +929,27 @@ test: biba/high &prompt.root; sysctl net.inet.ip.portrange.reservedlow=0 &prompt.root; sysctl net.inet.ip.portrange.reservedhigh=0 - To prevent the root - user from being affected by this policy, set - security.mac.portacl.suser_exempt to a - non-zero value. - - &prompt.root; sysctl security.mac.portacl.suser_exempt=1 - - To allow the www user with UID 80 - to bind to port 80 - without ever needing root privilege: - - &prompt.root; sysctl security.mac.portacl.rules=uid:80:tcp:80 - - This next example permits the user with the - UID of 1001 to bind to - TCP ports 110 (POP3) and - 995 (POP3s): + To prevent the root user from being affected + by this policy, set + security.mac.portacl.suser_exempt to a + non-zero value. + + &prompt.root; sysctl security.mac.portacl.suser_exempt=1 + + To allow the www + user with UID 80 to bind to port 80 + without ever needing root privilege: + + &prompt.root; sysctl security.mac.portacl.rules=uid:80:tcp:80 + + This next example permits the user with the + UID of 1001 to bind to + TCP ports 110 (POP3) and 995 + (POP3s): - &prompt.root; sysctl security.mac.portacl.rules=uid:1001:tcp:110,uid:1001:tcp:995 + &prompt.root; sysctl security.mac.portacl.rules=uid:1001:tcp:110,uid:1001:tcp:995 @@ -970,9 +968,10 @@ test: biba/high The &man.mac.partition.4; policy drops processes into specific partitions based on their - MAC label. Most configuration for this policy is done using - &man.setpmac.8;. One sysctl tunable is - available for this policy: + MAC label. Most configuration for this + policy is done using &man.setpmac.8;. One + sysctl tunable is available for this + policy: @@ -998,22 +997,21 @@ test: biba/high &prompt.root; setpmac partition/13 top - This command displays the partition label - and the process list: + This command displays the partition label and the process + list: + + &prompt.root; ps Zax + + This command displays another user's process partition + label and that user's currently running processes: - &prompt.root; ps Zax + &prompt.root; ps -ZU trhodes - This command displays another user's process - partition label and that user's currently running - processes: - - &prompt.root; ps -ZU trhodes - - - Users can see processes in root's label unless the - &man.mac.seeotheruids.4; policy is loaded. - + + Users can see processes in root's label unless the + &man.mac.seeotheruids.4; policy is loaded. + @@ -1036,36 +1034,33 @@ test: biba/high In MLS environments, a clearance level is set in the label of each subject or object, along with compartments. Since these - clearance levels can reach numbers greater than - several thousand, it would be a daunting task - to thoroughly configure every subject or object. - To ease this administrative overhead, three labels are included - in this policy: mls/low, - mls/equal and mls/high, - where: + clearance levels can reach numbers greater than several + thousand, it would be a daunting task to thoroughly configure + every subject or object. To ease this administrative + overhead, three labels are included in this policy: + mls/low, mls/equal and + mls/high, where: - Anything labeled with - mls/low will have a low clearance level - and not be permitted to access information of a higher - level. This label also prevents objects of a higher - clearance level from writing or passing information to a - lower level. + Anything labeled with mls/low will + have a low clearance level and not be permitted to access + information of a higher level. This label also prevents + objects of a higher clearance level from writing or + passing information to a lower level. - mls/equal should be - placed on objects which should be exempt from the - policy. + mls/equal should be placed on + objects which should be exempt from the policy. - mls/high is the highest - level of clearance possible. Objects assigned this label - will hold dominance over all other objects in the system; - however, they will not permit the leaking of information - to objects of a lower class. + mls/high is the highest level of + clearance possible. Objects assigned this label will hold + dominance over all other objects in the system; however, + they will not permit the leaking of information to objects + of a lower class. @@ -1141,29 +1136,28 @@ test: biba/high MLS policy information and to feed that file to setfmac. - When using the MLS policy module, an administrator plans - to control the flow of sensitive information. The default - block read up block write down sets - everything to a low state. Everything is accessible and an - administrator slowly augments the confidentiality of the - information. - - Beyond the three basic label options, an administrator - may group users and groups as required to block the - information flow between them. It might be easier to look - at the information in clearance levels using descriptive - words, such as classifications of - Confidential, Secret, - and Top Secret. Some administrators - instead create different groups based on project levels. - Regardless of the classification method, a well thought out - plan must exist before implementing a restrictive - policy. - - Some example situations for the MLS policy module - include an e-commerce web server, a file server holding - critical company information, and financial institution - environments. + When using the MLS policy module, an + administrator plans to control the flow of sensitive + information. The default block read up block write + down sets everything to a low state. Everything + is accessible and an administrator slowly augments the + confidentiality of the information. + + Beyond the three basic label options, an administrator + may group users and groups as required to block the + information flow between them. It might be easier to look at + the information in clearance levels using descriptive words, + such as classifications of Confidential, + Secret, and Top Secret. + Some administrators instead create different groups based on + project levels. Regardless of the classification method, a + well thought out plan must exist before implementing a + restrictive policy. + + Some example situations for the MLS + policy module include an e-commerce web server, a file server + holding critical company information, and financial + institution environments. @@ -1198,23 +1192,22 @@ test: biba/high - biba/low is considered - the lowest integrity an object or subject may have. - Setting this on objects or subjects blocks their write - access to objects or subjects marked as biba/high, but will not prevent - read access. + biba/low is considered the lowest + integrity an object or subject may have. Setting this on + objects or subjects blocks their write access to objects + or subjects marked as biba/high, but + will not prevent read access. - biba/equal should only be - placed on objects considered to be exempt from the - policy. + biba/equal should only be placed on + objects considered to be exempt from the policy. - biba/high permits - writing to objects set at a lower label, but does not permit - reading that object. It is recommended that this label be + biba/high permits writing to + objects set at a lower label, but does not permit reading + that object. It is recommended that this label be placed on objects that affect the integrity of the entire system. @@ -1243,13 +1236,13 @@ test: biba/high - Integrity levels instead of MLS sensitivity - levels. + Integrity levels instead of MLS + sensitivity levels. - The following tunables can be - used to manipulate the Biba policy: + The following tunables can be used to manipulate the Biba + policy: @@ -1279,41 +1272,38 @@ test: biba/high &prompt.root; getfmac test test: biba/low - Integrity, which is different from sensitivity, is used to - guarantee that information is not manipulated by - untrusted parties. This includes information passed between - subjects and objects. It ensures that users will - only be able to modify or access information they have been given explicit - access to. The &man.mac.biba.4; security policy module permits an - administrator to configure which files and programs a user may - see and invoke while assuring that the programs and files - are trusted by the system for that - user. - - During the initial planning phase, an administrator must - be prepared to partition users into grades, levels, and - areas. - The system will default to a high label once this policy - module is enabled, and it is up to the administrator to - configure the different grades and levels for users. - Instead of using clearance levels, a good planning method - could include topics. For instance, only allow developers - modification access to the source code repository, source - code compiler, and other development utilities. Other users - would be grouped into other categories such as testers, - designers, or end users and would only be permitted read - access. - - A lower integrity subject is unable to write to a higher - integrity subject and a higher integrity subject cannot - list or read a lower integrity object. Setting a label - at the lowest possible grade could make it inaccessible to - subjects. Some prospective environments for this security - policy module would include a constrained web server, a - development and test machine, and a source code repository. - A less useful implementation would be a personal - workstation, a machine used as a router, or a network - firewall. + Integrity, which is different from sensitivity, is used to + guarantee that information is not manipulated by untrusted + parties. This includes information passed between subjects + and objects. It ensures that users will only be able to + modify or access information they have been given explicit + access to. The &man.mac.biba.4; security policy module + permits an administrator to configure which files and programs + a user may see and invoke while assuring that the programs and + files are trusted by the system for that user. + + During the initial planning phase, an administrator must + be prepared to partition users into grades, levels, and areas. + The system will default to a high label once this policy + module is enabled, and it is up to the administrator to + configure the different grades and levels for users. Instead + of using clearance levels, a good planning method could + include topics. For instance, only allow developers + modification access to the source code repository, source + code compiler, and other development utilities. Other users + would be grouped into other categories such as testers, + designers, or end users and would only be permitted read + access. + + A lower integrity subject is unable to write to a higher + integrity subject and a higher integrity subject cannot list + or read a lower integrity object. Setting a label at the + lowest possible grade could make it inaccessible to subjects. + Some prospective environments for this security policy module + would include a constrained web server, a development and test + machine, and a source code repository. A less useful + implementation would be a personal workstation, a machine used + as a router, or a network firewall. @@ -1335,34 +1325,33 @@ test: biba/low objects only after decreasing the integrity level to not disrupt any integrity rules. - The Low-watermark - integrity policy works almost identically to Biba, with - the exception of using floating labels to support subject - demotion via an auxiliary grade compartment. This secondary - compartment takes the form [auxgrade]. - When assigning a policy with an auxiliary grade, use the - syntax lomac/10[2], where + The Low-watermark integrity policy works almost + identically to Biba, with the exception of using floating + labels to support subject demotion via an auxiliary grade + compartment. This secondary compartment takes the form + [auxgrade]. When assigning a policy with + an auxiliary grade, use the syntax + lomac/10[2], where 2 is the auxiliary grade. - This policy relies on the - ubiquitous labeling of all system objects with integrity - labels, permitting subjects to read from low integrity objects - and then downgrading the label on the subject to prevent - future writes to high integrity objects using - [auxgrade]. The policy may provide - greater compatibility and require less initial configuration - than Biba. - - Like the Biba and MLS policies, - setfmac and setpmac - are used to place labels on system objects: + This policy relies on the ubiquitous labeling of all + system objects with integrity labels, permitting subjects to + read from low integrity objects and then downgrading the label + on the subject to prevent future writes to high integrity + objects using [auxgrade]. The policy may + provide greater compatibility and require less initial + configuration than Biba. + + Like the Biba and MLS policies, + setfmac and setpmac + are used to place labels on system objects: - &prompt.root; setfmac /usr/home/trhodes lomac/high[low] + &prompt.root; setfmac /usr/home/trhodes lomac/high[low] &prompt.root; getfmac /usr/home/trhodes lomac/high[low] - The auxiliary grade low is a feature - provided only by the MAC LOMAC - policy. + The auxiliary grade low is a feature + provided only by the MAC + LOMAC policy.