diff options
Diffstat (limited to 'en_US.ISO8859-1/books/handbook/mac')
| -rw-r--r-- | en_US.ISO8859-1/books/handbook/mac/chapter.xml | 479 |
1 files changed, 234 insertions, 245 deletions
diff --git a/en_US.ISO8859-1/books/handbook/mac/chapter.xml b/en_US.ISO8859-1/books/handbook/mac/chapter.xml index 8851e2f08e..db85fced1b 100644 --- a/en_US.ISO8859-1/books/handbook/mac/chapter.xml +++ b/en_US.ISO8859-1/books/handbook/mac/chapter.xml @@ -552,10 +552,10 @@ test: biba/high</screen> <sect1 xml:id="mac-planning"> <title>Planning the Security Configuration</title> - <para>Before implementing any <acronym>MAC</acronym> policies, a planning phase - is recommended. During the planning stages, an administrator - should consider the implementation requirements and - goals, such as:</para> + <para>Before implementing any <acronym>MAC</acronym> policies, a + planning phase is recommended. During the planning stages, an + administrator should consider the implementation requirements + and goals, such as:</para> <itemizedlist> <listitem> @@ -570,32 +570,30 @@ test: biba/high</screen> </listitem> <listitem> - <para>Which <acronym>MAC</acronym> modules will be - required to achieve this goal.</para> + <para>Which <acronym>MAC</acronym> modules will be required to + achieve this goal.</para> </listitem> </itemizedlist> - <para>A trial run of the trusted - system and its configuration should occur - <emphasis>before</emphasis> a <acronym>MAC</acronym> - 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.</para> - - <para>Consider how the - <acronym>MAC</acronym> framework augments the security of - the system as a whole. The various security policy modules - provided by the <acronym>MAC</acronym> 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 <acronym>MLS</acronym> 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 <acronym>MLS</acronym> is increased - administrative overhead.</para> + <para>A trial run of the trusted system and its configuration + should occur <emphasis>before</emphasis> a + <acronym>MAC</acronym> 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.</para> + + <para>Consider how the <acronym>MAC</acronym> framework augments + the security of the system as a whole. The various security + policy modules provided by the <acronym>MAC</acronym> 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 + <acronym>MLS</acronym> 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 + <acronym>MLS</acronym> is increased administrative + overhead.</para> <para>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</screen> <acronym>MAC</acronym> access rules is in the hands of the system administrator.</para> - <para>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; + <para>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</screen> framework will help administrators choose the best policies for their situations.</para> - <para> The rest of this chapter covers the available - modules, describes their use and configuration, and in some - cases, provides insight on applicable situations.</para> + <para> The rest of this chapter covers the available modules, + describes their use and configuration, and in some cases, + provides insight on applicable situations.</para> <caution> <para>Implementing <acronym>MAC</acronym> 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 <acronym>MAC</acronym> over a remote connection should be - done with extreme caution.</para> + 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 <acronym>MAC</acronym> over a remote + connection should be done with extreme caution.</para> </caution> </sect1> @@ -664,14 +662,14 @@ test: biba/high</screen> <title>Available MAC Policies</title> <para>Beginning with &os; 8.0, the default &os; kernel - includes <literal>options MAC</literal>. This means that - every module included with the <acronym>MAC</acronym> - framework can be loaded with <command>kldload</command> as a run-time kernel module. - After testing the module, add the module name to + includes <literal>options MAC</literal>. This means that every + module included with the <acronym>MAC</acronym> framework can be + loaded with <command>kldload</command> as a run-time kernel + module. After testing the module, add the module name to <filename>/boot/loader.conf</filename> 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.</para> + during boot. Each module also provides a kernel option for + those administrators who choose to compile their own custom + kernel.</para> <para>&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</screen> <para>Boot option: <literal>mac_seeotheruids_load="YES"</literal></para> - <para>The &man.mac.seeotheruids.4; module extends - the <varname>security.bsd.see_other_uids</varname> and + <para>The &man.mac.seeotheruids.4; module extends the + <varname>security.bsd.see_other_uids</varname> and <varname>security.bsd.see_other_gids</varname> <command>sysctl</command> tunables. This option does not require any labels to be set before configuration and can @@ -707,9 +705,9 @@ test: biba/high</screen> <itemizedlist> <listitem> <para><varname>security.mac.seeotheruids.enabled</varname> - enables the module and implements the default settings which - deny users the ability to view processes and sockets owned - by other users.</para> + enables the module and implements the default settings + which deny users the ability to view processes and sockets + owned by other users.</para> </listitem> <listitem> @@ -750,15 +748,14 @@ test: biba/high</screen> <para>Boot option: <literal>mac_bsdextended_load="YES"</literal></para> - <para>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 + <para>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 <varname>security.mac.bsdextended.firstmatch_enabled</varname>. 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</screen> written by using the functions in the &man.libugidfw.3; library.</para> - <para>After the &man.mac.bsdextended.4; module has been - loaded, the following command may be used to list the - current rule configuration:</para> + <para>After the &man.mac.bsdextended.4; module has been loaded, + the following command may be used to list the current rule + configuration:</para> - <screen>&prompt.root; <userinput>ugidfw list</userinput> + <screen>&prompt.root; <userinput>ugidfw list</userinput> 0 slots, 0 rules</screen> - <para>By default, no rules are defined and everything is - completely accessible. To create a rule which blocks - all access by users but leaves <systemitem - class="username">root</systemitem> unaffected:</para> + <para>By default, no rules are defined and everything is + completely accessible. To create a rule which blocks all + access by users but leaves <systemitem + class="username">root</systemitem> unaffected:</para> - <screen>&prompt.root; <userinput>ugidfw add subject not uid root new object not uid root mode n</userinput></screen> + <screen>&prompt.root; <userinput>ugidfw add subject not uid root new object not uid root mode n</userinput></screen> - <para>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 - <systemitem class="username">user1</systemitem> all - access, including directory listings, to <systemitem - class="username"><replaceable>user2</replaceable></systemitem>'s - home directory:</para> + <para>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 <systemitem + class="username">user1</systemitem> all access, including + directory listings, to <systemitem + class="username"><replaceable>user2</replaceable></systemitem>'s + home directory:</para> <screen>&prompt.root; <userinput>ugidfw set 2 subject uid <replaceable>user1</replaceable> object uid <replaceable>user2</replaceable> mode n</userinput> &prompt.root; <userinput>ugidfw set 3 subject uid <replaceable>user1</replaceable> object gid <replaceable>user2</replaceable> mode n</userinput></screen> - <para>Instead of <systemitem - class="username">user1</systemitem>, <option>not - uid <replaceable>user2</replaceable></option> could be - used in order to enforce the same access restrictions for all - users. However, the <systemitem class="username">root</systemitem> - user is unaffected by these rules.</para> - - <note> - <para>Extreme caution should be taken when working with this - module as incorrect use could block access to certain parts of - the file system.</para> + <para>Instead of <systemitem + class="username">user1</systemitem>, <option>not + uid <replaceable>user2</replaceable></option> could be used + in order to enforce the same access restrictions for all + users. However, the <systemitem + class="username">root</systemitem> user is unaffected by + these rules.</para> + + <note> + <para>Extreme caution should be taken when working with this + module as incorrect use could block access to certain + parts of the file system.</para> </note> </sect2> @@ -821,10 +820,10 @@ test: biba/high</screen> <para>Boot option: <literal>mac_ifoff_load="YES"</literal></para> - <para>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 + <para>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 <acronym>MAC</acronym> modules.</para> <para>Most of this module's control is performed through these @@ -853,8 +852,8 @@ test: biba/high</screen> <para>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 - <package>security/aide</package> to automatically block + use would be to write a script which uses an application such + as <package>security/aide</package> to automatically block network traffic if it finds new or altered files in protected directories.</para> </sect2> @@ -904,19 +903,18 @@ test: biba/high</screen> <listitem> <para><varname>security.mac.portacl.rules</varname> - specifies the policy as a text string - of the form <literal>rule[,rule,...]</literal>, with as - many rules as needed, and where each rule is of the form + specifies the policy as a text string of the form + <literal>rule[,rule,...]</literal>, with as many rules as + needed, and where each rule is of the form <literal>idtype:id:protocol:port</literal>. The <parameter>idtype</parameter> is either <literal>uid</literal> or <literal>gid</literal>. The <parameter>protocol</parameter> parameter can be - <literal>tcp</literal> or - <literal>udp</literal>. The + <literal>tcp</literal> or <literal>udp</literal>. The <parameter>port</parameter> 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.</para> + and port parameters.</para> </listitem> </itemizedlist> @@ -931,27 +929,27 @@ test: biba/high</screen> &prompt.root; <userinput>sysctl net.inet.ip.portrange.reservedlow=0</userinput> &prompt.root; <userinput>sysctl net.inet.ip.portrange.reservedhigh=0</userinput></screen> - <para>To prevent the <systemitem class="username">root</systemitem> - user from being affected by this policy, set - <varname>security.mac.portacl.suser_exempt</varname> to a - non-zero value.</para> + <para>To prevent the <systemitem + class="username">root</systemitem> user from being affected + by this policy, set + <varname>security.mac.portacl.suser_exempt</varname> to a + non-zero value.</para> - <screen>&prompt.root; <userinput>sysctl security.mac.portacl.suser_exempt=1</userinput></screen> + <screen>&prompt.root; <userinput>sysctl security.mac.portacl.suser_exempt=1</userinput></screen> - <para>To allow the <systemitem - class="username">www</systemitem> user with <acronym>UID</acronym> 80 - to bind to port 80 - without ever needing <systemitem - class="username">root</systemitem> privilege:</para> + <para>To allow the <systemitem class="username">www</systemitem> + user with <acronym>UID</acronym> 80 to bind to port 80 + without ever needing <systemitem + class="username">root</systemitem> privilege:</para> - <screen>&prompt.root; <userinput>sysctl security.mac.portacl.rules=uid:80:tcp:80</userinput></screen> + <screen>&prompt.root; <userinput>sysctl security.mac.portacl.rules=uid:80:tcp:80</userinput></screen> - <para>This next example permits the user with the - <acronym>UID</acronym> of 1001 to bind to - <acronym>TCP</acronym> ports 110 (POP3) and - 995 (POP3s):</para> + <para>This next example permits the user with the + <acronym>UID</acronym> of 1001 to bind to + <acronym>TCP</acronym> ports 110 (POP3) and 995 + (POP3s):</para> - <screen>&prompt.root; <userinput>sysctl security.mac.portacl.rules=uid:1001:tcp:110,uid:1001:tcp:995</userinput></screen> + <screen>&prompt.root; <userinput>sysctl security.mac.portacl.rules=uid:1001:tcp:110,uid:1001:tcp:995</userinput></screen> </sect2> <sect2 xml:id="mac-partition"> @@ -970,9 +968,10 @@ test: biba/high</screen> <para>The &man.mac.partition.4; policy drops processes into specific <quote>partitions</quote> based on their - <acronym>MAC</acronym> label. Most configuration for this policy is done using - &man.setpmac.8;. One <command>sysctl</command> tunable is - available for this policy:</para> + <acronym>MAC</acronym> label. Most configuration for this + policy is done using &man.setpmac.8;. One + <command>sysctl</command> tunable is available for this + policy:</para> <itemizedlist> <listitem> @@ -998,22 +997,21 @@ test: biba/high</screen> <screen>&prompt.root; <userinput>setpmac partition/13 top</userinput></screen> - <para>This command displays the partition label - and the process list:</para> + <para>This command displays the partition label and the process + list:</para> - <screen>&prompt.root; <userinput>ps Zax</userinput></screen> + <screen>&prompt.root; <userinput>ps Zax</userinput></screen> - <para>This command displays another user's process - partition label and that user's currently running - processes:</para> + <para>This command displays another user's process partition + label and that user's currently running processes:</para> - <screen>&prompt.root; <userinput>ps -ZU trhodes</userinput></screen> + <screen>&prompt.root; <userinput>ps -ZU trhodes</userinput></screen> - <note> - <para>Users can see processes in <systemitem - class="username">root</systemitem>'s label unless the - &man.mac.seeotheruids.4; policy is loaded.</para> - </note> + <note> + <para>Users can see processes in <systemitem + class="username">root</systemitem>'s label unless the + &man.mac.seeotheruids.4; policy is loaded.</para> + </note> </sect2> <sect2 xml:id="mac-mls"> @@ -1036,36 +1034,33 @@ test: biba/high</screen> <para>In <acronym>MLS</acronym> environments, a <quote>clearance</quote> 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: <literal>mls/low</literal>, - <literal>mls/equal</literal> and <literal>mls/high</literal>, - where:</para> + 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: + <literal>mls/low</literal>, <literal>mls/equal</literal> and + <literal>mls/high</literal>, where:</para> <itemizedlist> <listitem> - <para>Anything labeled with - <literal>mls/low</literal> 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.</para> + <para>Anything labeled with <literal>mls/low</literal> 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.</para> </listitem> <listitem> - <para><literal>mls/equal</literal> should be - placed on objects which should be exempt from the - policy.</para> + <para><literal>mls/equal</literal> should be placed on + objects which should be exempt from the policy.</para> </listitem> <listitem> - <para><literal>mls/high</literal> 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.</para> + <para><literal>mls/high</literal> 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.</para> </listitem> </itemizedlist> @@ -1141,29 +1136,28 @@ test: biba/high</screen> <acronym>MLS</acronym> policy information and to feed that file to <command>setfmac</command>.</para> - <para>When using the <acronym>MLS</acronym> policy module, an administrator plans - to control the flow of sensitive information. The default - <literal>block read up block write down</literal> sets - everything to a low state. Everything is accessible and an - administrator slowly augments the confidentiality of the - information.</para> - - <para>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 - <literal>Confidential</literal>, <literal>Secret</literal>, - and <literal>Top Secret</literal>. 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.</para> - - <para>Some example situations for the <acronym>MLS</acronym> policy module - include an e-commerce web server, a file server holding - critical company information, and financial institution - environments.</para> + <para>When using the <acronym>MLS</acronym> policy module, an + administrator plans to control the flow of sensitive + information. The default <literal>block read up block write + down</literal> sets everything to a low state. Everything + is accessible and an administrator slowly augments the + confidentiality of the information.</para> + + <para>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 <literal>Confidential</literal>, + <literal>Secret</literal>, and <literal>Top Secret</literal>. + 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.</para> + + <para>Some example situations for the <acronym>MLS</acronym> + policy module include an e-commerce web server, a file server + holding critical company information, and financial + institution environments.</para> </sect2> <sect2 xml:id="mac-biba"> @@ -1198,23 +1192,22 @@ test: biba/high</screen> <itemizedlist> <listitem> - <para><literal>biba/low</literal> 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 <literal>biba/high</literal>, but will not prevent - read access.</para> + <para><literal>biba/low</literal> 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 <literal>biba/high</literal>, but + will not prevent read access.</para> </listitem> <listitem> - <para><literal>biba/equal</literal> should only be - placed on objects considered to be exempt from the - policy.</para> + <para><literal>biba/equal</literal> should only be placed on + objects considered to be exempt from the policy.</para> </listitem> <listitem> - <para><literal>biba/high</literal> permits - writing to objects set at a lower label, but does not permit - reading that object. It is recommended that this label be + <para><literal>biba/high</literal> 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.</para> </listitem> @@ -1243,13 +1236,13 @@ test: biba/high</screen> </listitem> <listitem> - <para>Integrity levels instead of <acronym>MLS</acronym> sensitivity - levels.</para> + <para>Integrity levels instead of <acronym>MLS</acronym> + sensitivity levels.</para> </listitem> </itemizedlist> - <para>The following tunables can be - used to manipulate the Biba policy:</para> + <para>The following tunables can be used to manipulate the Biba + policy:</para> <itemizedlist> <listitem> @@ -1279,41 +1272,38 @@ test: biba/high</screen> &prompt.root; <userinput>getfmac test</userinput> test: biba/low</screen> - <para>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.</para> - - <para>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.</para> - - <para>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.</para> + <para>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.</para> + + <para>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.</para> + + <para>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.</para> </sect2> <sect2 xml:id="mac-lomac"> @@ -1335,34 +1325,33 @@ test: biba/low</screen> objects only after decreasing the integrity level to not disrupt any integrity rules.</para> - <para>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 <literal>[auxgrade]</literal>. - When assigning a policy with an auxiliary grade, use the - syntax <literal>lomac/10[2]</literal>, where + <para>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 + <literal>[auxgrade]</literal>. When assigning a policy with + an auxiliary grade, use the syntax + <literal>lomac/10[2]</literal>, where <literal>2</literal> is the auxiliary grade.</para> - <para>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 - <literal>[auxgrade]</literal>. The policy may provide - greater compatibility and require less initial configuration - than Biba.</para> + <para>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 <literal>[auxgrade]</literal>. The policy may + provide greater compatibility and require less initial + configuration than Biba.</para> - <para>Like the Biba and <acronym>MLS</acronym> policies, - <command>setfmac</command> and <command>setpmac</command> - are used to place labels on system objects:</para> + <para>Like the Biba and <acronym>MLS</acronym> policies, + <command>setfmac</command> and <command>setpmac</command> + are used to place labels on system objects:</para> - <screen>&prompt.root; <userinput>setfmac /usr/home/trhodes lomac/high[low]</userinput> + <screen>&prompt.root; <userinput>setfmac /usr/home/trhodes lomac/high[low]</userinput> &prompt.root; <userinput>getfmac /usr/home/trhodes lomac/high[low]</userinput></screen> - <para>The auxiliary grade <literal>low</literal> is a feature - provided only by the <acronym>MAC</acronym> <acronym>LOMAC</acronym> - policy.</para> + <para>The auxiliary grade <literal>low</literal> is a feature + provided only by the <acronym>MAC</acronym> + <acronym>LOMAC</acronym> policy.</para> </sect2> </sect1> |