Date: Wed, 30 Jan 2013 14:22:19 +0000 (UTC) From: Dru Lavigne <dru@FreeBSD.org> To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r40819 - head/en_US.ISO8859-1/books/handbook/mac Message-ID: <201301301422.r0UEMJxB064163@svn.freebsd.org>
next in thread | raw e-mail | index | archive | help
Author: dru Date: Wed Jan 30 14:22:19 2013 New Revision: 40819 URL: http://svnweb.freebsd.org/changeset/doc/40819 Log: White space fix only. Translators can ignore. Approved by: bcr (mentor) 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 Wed Jan 30 14:00:53 2013 (r40818) +++ head/en_US.ISO8859-1/books/handbook/mac/chapter.xml Wed Jan 30 14:22:19 2013 (r40819) @@ -27,38 +27,39 @@ </indexterm> <para>&os; 5.X introduced new security extensions from the - TrustedBSD project based on the &posix;.1e draft. Two of the most - significant new security mechanisms are file system Access Control - Lists (<acronym>ACL</acronym>s) and Mandatory Access Control - (<acronym>MAC</acronym>) facilities. Mandatory Access Control allows - new access control modules to be loaded, implementing new security - policies. Some provide protections of a narrow subset of the - system, hardening a particular service. Others provide - comprehensive labeled security across all subjects and objects. - The mandatory part - of the definition comes from the fact that the enforcement of - the controls is done by administrators and the system, and is - not left up to the discretion of users as is done with - discretionary access control (<acronym>DAC</acronym>, the standard - file and System V <acronym>IPC</acronym> permissions on &os;).</para> + TrustedBSD project based on the &posix;.1e draft. Two of the + most significant new security mechanisms are file system Access + Control Lists (<acronym>ACL</acronym>s) and Mandatory Access + Control (<acronym>MAC</acronym>) facilities. Mandatory Access + Control allows new access control modules to be loaded, + implementing new security policies. Some provide protections + of a narrow subset of the system, hardening a particular + service. Others provide comprehensive labeled security across + all subjects and objects. The mandatory part of the definition + comes from the fact that the enforcement of the controls is + done by administrators and the system, and is not left up to + the discretion of users as is done with discretionary access + control (<acronym>DAC</acronym>, the standard file and System + V <acronym>IPC</acronym> permissions on &os;).</para> <para>This chapter will focus on the - Mandatory Access Control Framework (<acronym>MAC</acronym> Framework), and a set - of pluggable security policy modules enabling various security - mechanisms.</para> + Mandatory Access Control Framework (<acronym>MAC</acronym> + Framework), and a set of pluggable security policy modules + enabling various security mechanisms.</para> <para>After reading this chapter, you will know:</para> <itemizedlist> <listitem> - <para>What <acronym>MAC</acronym> security policy modules are currently - included in &os; and their associated mechanisms.</para> + <para>What <acronym>MAC</acronym> security policy modules + are currently included in &os; and their associated + mechanisms.</para> </listitem> <listitem> - <para>What <acronym>MAC</acronym> security policy modules implement as - well as the difference between a labeled and non-labeled - policy.</para> + <para>What <acronym>MAC</acronym> security policy modules + implement as well as the difference between a labeled and + non-labeled policy.</para> </listitem> <listitem> @@ -67,19 +68,20 @@ </listitem> <listitem> - <para>How to configure the different security policy modules included with the - <acronym>MAC</acronym> framework.</para> + <para>How to configure the different security policy modules + included with the <acronym>MAC</acronym> framework.</para> </listitem> <listitem> - <para>How to implement a more secure environment using the + <para>How to implement a more secure environment using the <acronym>MAC</acronym> framework and the examples shown.</para> </listitem> <listitem> <para>How to test the <acronym>MAC</acronym> configuration - to ensure the framework has been properly implemented.</para> + to ensure the framework has been properly + implemented.</para> </listitem> </itemizedlist> @@ -107,36 +109,37 @@ <para>The improper use of the information contained herein may cause loss of system access, aggravation of users, or inability to access the features - provided by X11. More importantly, <acronym>MAC</acronym> should not - be relied upon to completely secure a system. The - <acronym>MAC</acronym> framework only augments - existing security policy; without sound security practices and + provided by X11. More importantly, <acronym>MAC</acronym> + should not be relied upon to completely secure a system. The + <acronym>MAC</acronym> framework only augments existing + security policy; without sound security practices and regular security checks, the system will never be completely secure.</para> <para>It should also be noted that the examples contained within this chapter are just that, examples. It is not recommended that these particular settings be rolled out - on a production system. Implementing the various security policy modules takes - a good deal of thought and testing. One who does not fully understand - exactly how everything works may find him or herself going - back through the entire system and reconfiguring many files - or directories.</para> + on a production system. Implementing the various security + policy modules takes a good deal of thought and testing. One + who does not fully understand exactly how everything works + may find him or herself going back through the entire system + and reconfiguring many files or directories.</para> </warning> <sect2> <title>What Will Not Be Covered</title> - <para>This chapter covers a broad range of security issues relating - to the <acronym>MAC</acronym> framework. The - development of new <acronym>MAC</acronym> security policy modules - will not be covered. A number of security policy modules included with the - <acronym>MAC</acronym> framework have specific characteristics - which are provided for both testing and new module - development. These include the &man.mac.test.4;, - &man.mac.stub.4; and &man.mac.none.4;. - For more information on these security policy modules and the various - mechanisms they provide, please review the manual pages.</para> + <para>This chapter covers a broad range of security issues + relating to the <acronym>MAC</acronym> framework. The + development of new <acronym>MAC</acronym> security policy + modules will not be covered. A number of security policy + modules included with the <acronym>MAC</acronym> framework + have specific characteristics which are provided for both + testing and new module development. These include the + &man.mac.test.4;, &man.mac.stub.4; and &man.mac.none.4;. + For more information on these security policy modules and + the various mechanisms they provide, please review the manual + pages.</para> </sect2> </sect1> @@ -165,29 +168,29 @@ for the purpose of accessing higher level information. In most cases, the original level is restored after the process is complete. Currently, the &os; <acronym>MAC</acronym> - framework does not have a policy for this, but the definition - is included for completeness.</para> + framework does not have a policy for this, but the + definition is included for completeness.</para> </listitem> <listitem> <para><emphasis>integrity</emphasis>: Integrity, as a key concept, is the level of trust which can be placed on data. - As the integrity of the data is elevated, so does the ability - to trust that data.</para> + As the integrity of the data is elevated, so does the + ability to trust that data.</para> </listitem> <listitem> <para><emphasis>label</emphasis>: A label is a security attribute which can be applied to files, directories, or - other items in the system. It could be considered - a confidentiality stamp; when a label is placed on - a file it describes the security properties for that specific + other items in the system. It could be considered a + confidentiality stamp; when a label is placed on a file it + describes the security properties for that specific file and will only permit access by files, users, resources, etc. with a similar security setting. The meaning and - interpretation of label values depends on the policy configuration: while - some policies might treat a label as representing the - integrity or secrecy of an object, other policies might use - labels to hold rules for access.</para> + interpretation of label values depends on the policy + configuration: while some policies might treat a label as + representing the integrity or secrecy of an object, other + policies might use labels to hold rules for access.</para> </listitem> <listitem> @@ -213,20 +216,21 @@ &man.tunefs.8; utility, during the boot operation using the &man.fstab.5; file, or during the creation of a new file system. This option will permit an administrator - to apply different <acronym>MAC</acronym> labels on different - objects. This option - only applies to security policy modules which support labeling.</para> + to apply different <acronym>MAC</acronym> labels on + different objects. This option only applies to security + policy modules which support labeling.</para> </listitem> <listitem> <para><emphasis>object</emphasis>: An object or system object is an entity through which information flows under the direction of a <emphasis>subject</emphasis>. - This includes directories, files, fields, screens, keyboards, - memory, magnetic storage, printers or any other data - storage/moving device. Basically, an object is a data container or - a system resource; access to an <emphasis>object</emphasis> - effectively means access to the data.</para> + This includes directories, files, fields, screens, + keyboards, memory, magnetic storage, printers or any other + data storage/moving device. Basically, an object is a data + container or a system resource; access to an + <emphasis>object</emphasis> effectively means access to the + data.</para> </listitem> <listitem> @@ -246,7 +250,8 @@ discussing <acronym>MLS</acronym>. A sensitivity level is a term used to describe how important or secret the data should be. As the sensitivity level increases, so does the - importance of the secrecy, or confidentiality of the data.</para> + importance of the secrecy, or confidentiality of the + data.</para> </listitem> <listitem> @@ -262,8 +267,8 @@ <para><emphasis>subject</emphasis>: a subject is any active entity that causes information to flow between <emphasis>objects</emphasis>; e.g., a user, user process, - system process, etc. On &os;, this is almost always a thread - acting in a process on behalf of a user.</para> + system process, etc. On &os;, this is almost always a + thread acting in a process on behalf of a user.</para> </listitem> </itemizedlist> </sect1> @@ -273,53 +278,56 @@ <para>With all of these new terms in mind, 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, block users from - accessing certain ports and sockets, and more. Perhaps - the best use of the policy modules is to blend them together, by loading - several security policy modules at a time for a multi-layered - security environment. In a multi-layered security environment, - multiple policy modules are in effect to keep security in check. This - is different to a hardening policy, which typically hardens - elements of a system that is used only for specific purposes. - The only downside is administrative overhead in cases of - multiple file system labels, setting network access control - user by user, etc.</para> + 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, block users from + accessing certain ports and sockets, and more. Perhaps the + best use of the policy modules is to blend them together, by + loading several security policy modules at a time for a + multi-layered security environment. In a multi-layered security + environment, multiple policy modules are in effect to keep + security in check. This is different to a hardening policy, + which typically hardens elements of a system that is used only + for specific purposes. The only downside is administrative + overhead in cases of multiple file system labels, setting + network access control user by user, etc.</para> <para>These downsides are minimal when compared to the lasting - effect of the framework; for instance, the ability to pick and choose - which policies are required for a specific configuration keeps - performance overhead down. The reduction of support for unneeded - policies can increase the overall performance of the system as well as - offer flexibility of choice. A good implementation would - consider the overall security requirements and effectively implement - the various security policy modules offered by the framework.</para> + effect of the framework; for instance, the ability to pick + and choose which policies are required for a specific + configuration keeps performance overhead down. The reduction + of support for unneeded policies can increase the overall + performance of the system as well as offer flexibility of + choice. A good implementation would consider the overall + security requirements and effectively implement the various + security policy modules offered by the framework.</para> <para>Thus a system utilizing <acronym>MAC</acronym> features should at least guarantee that a user will not be permitted to change security attributes at will; all user utilities, programs and scripts must work within the constraints of - the access rules provided by the selected security policy modules; and - that total control of the <acronym>MAC</acronym> access - rules are in the hands of the system administrator.</para> + the access rules provided by the selected security policy + modules; and that total control of the <acronym>MAC</acronym> + access rules are in the hands of the system + administrator.</para> <para>It is the sole duty of the system administrator to - carefully select the correct security policy modules. Some environments - may need to limit access control over the network; in these - cases, the &man.mac.portacl.4;, &man.mac.ifoff.4; and even - &man.mac.biba.4; policy modules might make good starting points. In other - cases, strict confidentiality of file system objects might - be required. Policy modules such as &man.mac.bsdextended.4; - and &man.mac.mls.4; exist for this purpose.</para> + carefully select the correct security policy modules. Some + environments may need to limit access control over the network; + in these cases, the &man.mac.portacl.4;, &man.mac.ifoff.4; and + even &man.mac.biba.4; policy modules might make good starting + points. In other cases, strict confidentiality of file system + objects might be required. Policy modules such as + &man.mac.bsdextended.4; and &man.mac.mls.4; exist for this + purpose.</para> <para>Policy decisions could be made based on network configuration. Perhaps only certain users should be permitted access to facilities provided by &man.ssh.1; to access the network or the Internet. The &man.mac.portacl.4; would be - the policy module of choice for these situations. But what should be - done in the case of file systems? Should all access to certain - directories be severed from other groups or specific + the policy module of choice for these situations. But what + should be done in the case of file systems? Should all access + to certain directories be severed from other groups or specific users? Or should we limit user or utility access to specific files by setting certain objects as classified?</para> @@ -330,19 +338,20 @@ project A might not be permitted to access objects written by developers in project B. Yet they might need to access objects created by developers in project C; that is quite a - situation indeed. Using the different security policy modules provided by - the <acronym>MAC</acronym> framework; users could + situation indeed. Using the different security policy modules + provided by the <acronym>MAC</acronym> framework; users could be divided into these groups and then given access to the appropriate areas without fear of information leakage.</para> - <para>Thus, each security policy module has a unique way of dealing with - the overall security of a system. Module selection should be based - on a well thought out security policy. In many cases, the - overall policy may need to be revised and reimplemented on - the system. Understanding the different security policy modules offered by - the <acronym>MAC</acronym> framework will help administrators - choose the best policies for their situations.</para> + <para>Thus, each security policy module has a unique way of + dealing with the overall security of a system. Module selection + should be based on a well thought out security policy. In many + cases, the overall policy may need to be revised and + reimplemented on the system. Understanding the different + security policy modules offered by the <acronym>MAC</acronym> + framework will help administrators choose the best policies + for their situations.</para> <para>The default &os; kernel does not include the option for the <acronym>MAC</acronym> framework; thus the following @@ -351,7 +360,8 @@ <programlisting>options MAC</programlisting> - <para>And the kernel will require a rebuild and a reinstall.</para> + <para>And the kernel will require a rebuild and a + reinstall.</para> <caution> <para>While the various manual pages for <acronym>MAC</acronym> @@ -375,11 +385,11 @@ <para>When setting a label, the user must be able to comprehend what it is, exactly, that is being done. The attributes - available on an object depend on the policy module loaded, and that - policy modules interpret their attributes in different - ways. If improperly configured due to lack of comprehension, or - the inability to understand the implications, the result will - be the unexpected and perhaps, undesired, behavior of the + available on an object depend on the policy module loaded, and + that policy modules interpret their attributes in different + ways. If improperly configured due to lack of comprehension, + or the inability to understand the implications, the result + will be the unexpected and perhaps, undesired, behavior of the system.</para> <para>The security label on an object is used as a part of a @@ -388,26 +398,27 @@ to make a decision; in other models, the labels may be processed as part of a larger rule set, etc.</para> - <para>For instance, setting the label of <literal>biba/low</literal> - on a file will represent a label maintained by the Biba security policy module, - with a value of <quote>low</quote>.</para> + <para>For instance, setting the label of + <literal>biba/low</literal> on a file will represent a label + maintained by the Biba security policy module, with a value + of <quote>low</quote>.</para> - <para>A few policy modules which support the labeling feature in - &os; offer three specific predefined labels. These + <para>A few policy modules which support the labeling feature + in &os; offer three specific predefined labels. These are the low, high, and equal labels. Although they enforce - access control in a different manner with each policy module, you - can be sure that the low label will be the lowest setting, + access control in a different manner with each policy module, + you can be sure that the low label will be the lowest setting, the equal label will set the subject or object to be disabled or unaffected, and the high label will enforce the highest setting available in the Biba and <acronym>MLS</acronym> policy modules.</para> - <para>Within single label file system environments, only one label may be - used on objects. This will enforce one set of + <para>Within single label file system environments, only one + label may be used on objects. This will enforce one set of access permissions across the entire system and in many environments may be all that is required. There are a few - cases where multiple labels may be set on objects - or subjects in the file system. For those cases, the + cases where multiple labels may be set on objects or subjects + in the file system. For those cases, the <option>multilabel</option> option may be passed to &man.tunefs.8;.</para> @@ -420,13 +431,14 @@ <para>In most cases the administrator will only be setting up a single label to use throughout the file system.</para> - <para><emphasis>Hey wait, this is similar to <acronym>DAC</acronym>! - I thought <acronym>MAC</acronym> gave control strictly to the - administrator.</emphasis> That statement still holds true, to some - extent as <username>root</username> is the one in control and who + <para><emphasis>Hey wait, this is similar to + <acronym>DAC</acronym>! I thought <acronym>MAC</acronym> gave + control strictly to the administrator.</emphasis> That + statement still holds true, to some extent as + <username>root</username> is the one in control and who configures the policies so that users are placed in the - appropriate categories/access levels. Alas, many policy modules can - restrict the <username>root</username> user as well. Basic + appropriate categories/access levels. Alas, many policy modules + can restrict the <username>root</username> user as well. Basic control over objects will then be released to the group, but <username>root</username> may revoke or modify the settings at any time. This is the hierarchal/clearance model covered @@ -456,18 +468,19 @@ &man.chmod.1; and &man.chown.8; commands. In some cases this error may be a <errorname>Permission denied</errorname> and is usually obtained when the label is being set or modified - on an object which is restricted.<footnote><para>Other conditions - may produce different failures. For instance, the file may not - be owned by the user attempting to relabel the object, the - object may not exist or may be read only. A mandatory policy - will not allow the process to relabel the file, maybe because - of a property of the file, a property of the process, or a - property of the proposed new label value. For example: a user - running at low integrity tries to change the label of a high - integrity file. Or perhaps a user running at low integrity - tries to change the label of a low integrity file to a high - integrity label.</para></footnote> The system administrator - may use the following commands to overcome this:</para> + on an object which is restricted.<footnote>Other conditions + may produce different failures. For instance, the file may + not be owned by the user attempting to relabel the object, + the object may not exist or may be read only. A mandatory + policy will not allow the process to relabel the file, maybe + because of a property of the file, a property of the + process, or a property of the proposed new label value. For + example: a user running at low integrity tries to change the + label of a high integrity file. Or perhaps a user running + at low integrity tries to change the label of a low + integrity file to a high integrity label.</footnote> The + system administrator may use the following commands to + overcome this:</para> <screen>&prompt.root; <userinput>setfmac biba/high test</userinput> <errorname>Permission denied</errorname> @@ -476,15 +489,15 @@ test: biba/high</screen> <para>As we see above, <command>setpmac</command> - can be used to override the policy module's settings by assigning - a different label to the invoked process. The - <command>getpmac</command> utility is usually used with currently - running processes, such as <application>sendmail</application>: - although it takes a process ID in place of - a command the logic is extremely similar. If users - attempt to manipulate a file not in their access, subject to the - rules of the loaded policy modules, the - <errorname>Operation not permitted</errorname> error + can be used to override the policy module's settings by + assigning a different label to the invoked process. The + <command>getpmac</command> utility is usually used with + currently running processes, such as + <application>sendmail</application>: although it takes a + process ID in place of a command the logic is extremely + similar. If users attempt to manipulate a file not in their + access, subject to the rules of the loaded policy modules, + the <errorname>Operation not permitted</errorname> error will be displayed by the <function>mac_set_link</function> function.</para> @@ -512,29 +525,30 @@ test: biba/high</screen> </listitem> <listitem> - <para>The <literal>high</literal> label grants an object or - subject the highest possible setting.</para> + <para>The <literal>high</literal> label grants an object + or subject the highest possible setting.</para> </listitem> </itemizedlist> - <para>With respect to each policy module, each of those settings - will instate a different information flow directive. Reading - the proper manual pages will further explain the traits of - these generic label configurations.</para> + <para>With respect to each policy module, each of those + settings will instate a different information flow + directive. Reading the proper manual pages will further + explain the traits of these generic label + configurations.</para> - <sect4> + <sect4> <title>Advanced Label Configuration</title> <para>Numeric grade labels are used for - <literal>comparison:compartment+compartment</literal>; thus - the following:</para> + <literal>comparison:compartment+compartment</literal>; + thus the following:</para> <programlisting>biba/10:2+3+6(5:2+3-20:2+3+4+5+6)</programlisting> <para>May be interpreted as:</para> - <para><quote>Biba Policy Label</quote>/<quote>Grade 10</quote> - :<quote>Compartments 2, 3 and 6</quote>: + <para><quote>Biba Policy Label</quote>/<quote>Grade + 10</quote>:<quote>Compartments 2, 3 and 6</quote>: (<quote>grade 5 ...</quote>)</para> <para>In this example, the first grade would be considered @@ -547,24 +561,24 @@ test: biba/high</screen> <para>When applied to system objects, they will only have a current grade/compartments as opposed to system subjects - as they reflect the range of available rights in the system, - and network interfaces, where they are used for access - control.</para> + as they reflect the range of available rights in the + system, and network interfaces, where they are used for + access control.</para> - <para>The grade and compartments in a subject and object pair - are used to construct a relationship referred to as + <para>The grade and compartments in a subject and object + pair are used to construct a relationship referred to as <quote>dominance</quote>, in which a subject dominates an - object, the object dominates the subject, neither dominates - the other, or both dominate each other. The - <quote>both dominate</quote> case occurs when the two labels - are equal. Due to the information flow nature of Biba, you - have rights to a set of compartments, + object, the object dominates the subject, neither + dominates the other, or both dominate each other. The + <quote>both dominate</quote> case occurs when the two + labels are equal. Due to the information flow nature of + Biba, you have rights to a set of compartments, <quote>need to know</quote>, that might correspond to projects, but objects also have a set of compartments. Users may have to subset their rights using - <command>su</command> or <command>setpmac</command> in order - to access objects in a compartment from which they are not - restricted.</para> + <command>su</command> or <command>setpmac</command> in + order to access objects in a compartment from which they + are not restricted.</para> </sect4> </sect3> @@ -575,11 +589,11 @@ test: biba/high</screen> their files and processes may properly interact with the security policy defined on the system. This is configured through the <filename>login.conf</filename> file - by use of login classes. Every policy module that uses labels - will implement the user class setting.</para> + by use of login classes. Every policy module that uses + labels will implement the user class setting.</para> - <para>An example entry containing every policy module setting is displayed - below:</para> + <para>An example entry containing every policy module setting + is displayed below:</para> <programlisting>default:\ :copyright=/etc/COPYRIGHT:\ @@ -657,8 +671,9 @@ test: biba/high</screen> <para>will set the <acronym>MAC</acronym> label of <literal>biba/equal</literal> on the &man.bge.4; interface. When using a setting similar to - <literal>biba/high(low-high)</literal> the entire label should - be quoted; otherwise an error will be returned.</para> + <literal>biba/high(low-high)</literal> the entire label + should be quoted; otherwise an error will be + returned.</para> <para>Each policy module which supports labeling has a tunable which may be used to disable the <acronym>MAC</acronym> @@ -698,8 +713,8 @@ test: biba/high</screen> <acronym>MLS</acronym> and <acronym>SEBSD</acronym> policies.</para> - <para>In many cases, the <option>multilabel</option> may not need - to be set at all. Consider the following situation and + <para>In many cases, the <option>multilabel</option> may not + need to be set at all. Consider the following situation and security model:</para> <itemizedlist> @@ -710,32 +725,32 @@ test: biba/high</screen> <listitem> <para>This machine only requires one label, - <literal>biba/high</literal>, for everything in the system. - Here the file system would not require the + <literal>biba/high</literal>, for everything in the + system. Here the file system would not require the <option>multilabel</option> option as a single label will always be in effect.</para> </listitem> <listitem> - <para>But, this machine will be a web server and should have - the web server run at <literal>biba/low</literal> to prevent - write up capabilities. The Biba policy and how it works - will be discussed later, so if the previous comment was - difficult to interpret just continue reading and return. - The server could use a separate partition set at - <literal>biba/low</literal> for most if not all of its - runtime state. Much is lacking from this example, for - instance the restrictions on data, configuration and user - settings; however, this is just a quick example to prove the - aforementioned point.</para> + <para>But, this machine will be a web server and should + have the web server run at <literal>biba/low</literal> + to prevent write up capabilities. The Biba policy and + how it works will be discussed later, so if the previous + comment was difficult to interpret just continue reading + and return. The server could use a separate partition + set at <literal>biba/low</literal> for most if not all + of its runtime state. Much is lacking from this example, + for instance the restrictions on data, configuration and + user settings; however, this is just a quick example to + prove the aforementioned point.</para> </listitem> </itemizedlist> <para>If any of the non-labeling policies are to be used, then the <option>multilabel</option> option would never - be required. These include the <literal>seeotheruids</literal>, - <literal>portacl</literal> and <literal>partition</literal> - policies.</para> + be required. These include the + <literal>seeotheruids</literal>, <literal>portacl</literal> + and <literal>partition</literal> policies.</para> <para>It should also be noted that using <option>multilabel</option> with a partition and establishing @@ -766,10 +781,11 @@ test: biba/high</screen> <sect1 id="mac-planning"> <title>Planning the Security Configuration</title> - <para>Whenever a new technology is implemented, a planning phase is - always a good idea. During the planning stages, an administrator - should in general look at the <quote>big picture</quote>, trying - to keep in view at least the following:</para> + <para>Whenever a new technology is implemented, a planning phase + is always a good idea. During the planning stages, an + administrator should in general look at the <quote>big + picture</quote>, trying to keep in view at least the + following:</para> <itemizedlist> <listitem> @@ -781,7 +797,8 @@ test: biba/high</screen> </listitem> </itemizedlist> - <para>For <acronym>MAC</acronym> installations, these include:</para> + <para>For <acronym>MAC</acronym> installations, these + include:</para> <itemizedlist> <listitem> @@ -802,15 +819,16 @@ test: biba/high</screen> </itemizedlist> <para>It is always possible to reconfigure and change the - system resources and security settings, it is quite often very inconvenient to - search through the system and fix existing files and user - accounts. Planning helps to ensure a trouble-free and efficient - trusted system implementation. A trial run of the trusted system, - including the configuration, is often vital and definitely - beneficial <emphasis>before</emphasis> a <acronym>MAC</acronym> - implementation is used on production systems. The idea of just - letting loose on a system - with <acronym>MAC</acronym> is like setting up for failure.</para> + system resources and security settings, it is quite often very + inconvenient to search through the system and fix existing + files and user accounts. Planning helps to ensure a + trouble-free and efficient trusted system implementation. A + trial run of the trusted system, including the configuration, + is often vital and definitely beneficial + <emphasis>before</emphasis> a <acronym>MAC</acronym> + implementation is used on production systems. The idea of + just letting loose on a system with <acronym>MAC</acronym> is + like setting up for failure.</para> <para>Different environments may have explicit needs and requirements. Establishing an in depth and complete security @@ -841,11 +859,11 @@ test: biba/high</screen> be a consideration of this chapter. Some modules support the use of labeling, which is controlling access by enforcing a label such as <quote>this is allowed and this is not</quote>. - A label configuration file may control how files may be accessed, - network communication can be exchanged, and more. The previous - section showed how the <option>multilabel</option> flag could - be set on file systems to enable per-file or per-partition - access control.</para> + A label configuration file may control how files may be + accessed, network communication can be exchanged, and more. + The previous section showed how the <option>multilabel</option> + flag could be set on file systems to enable per-file or + per-partition access control.</para> <para>A single label configuration would enforce only one label across the system, that is why the <command>tunefs</command> @@ -893,8 +911,8 @@ test: biba/high</screen> To exempt specific groups from this policy, use the <literal>security.mac.seeotheruids.specificgid=<replaceable>XXX</replaceable></literal> <command>sysctl</command> tunable. In the above example, - the <replaceable>XXX</replaceable> should be replaced with the - numeric group ID to be exempted.</para> + the <replaceable>XXX</replaceable> should be replaced with + the numeric group ID to be exempted.</para> </listitem> <listitem> @@ -912,8 +930,8 @@ test: biba/high</screen> <title>The MAC bsdextended Module</title> <indexterm> - <primary>MAC</primary> - <secondary>File System Firewall Policy</secondary> + <primary>MAC</primary> + <secondary>File System Firewall Policy</secondary> </indexterm> <para>Module name: <filename>mac_bsdextended.ko</filename></para> @@ -926,21 +944,21 @@ test: biba/high</screen> <para>The &man.mac.bsdextended.4; module enforces the file system firewall. This module's policy 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 by the use of a - &man.sysctl.8; parameter, + 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 by the use + of a &man.sysctl.8; parameter, security.mac.bsdextended.firstmatch_enabled. Similar to - other firewall modules in &os;, a file containing access control - rules can be created and read by the system at boot time using - an &man.rc.conf.5; variable.</para> - - <para>The rule list may be entered using a utility, &man.ugidfw.8;, - that has a syntax similar to that of &man.ipfw.8;. More tools - can be written by using the functions in the - &man.libugidfw.3; library.</para> + other firewall modules in &os;, a file containing access + control rules can be created and read by the system at boot + time using an &man.rc.conf.5; variable.</para> + + <para>The rule list may be entered using a utility, + &man.ugidfw.8;, that has a syntax similar to that of + &man.ipfw.8;. More tools can be written by using the functions + in the &man.libugidfw.3; library.</para> <para>Extreme caution should be taken when working with this module; incorrect use could block access to certain parts of @@ -949,9 +967,9 @@ test: biba/high</screen> <sect2> <title>Examples</title> - <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> 0 slots, 0 rules</screen> @@ -973,17 +991,19 @@ test: biba/high</screen> &prompt.root; <userinput>ugidfw set 3 subject uid <replaceable>user1</replaceable> object gid <replaceable>user2</replaceable> mode n</userinput></screen> <para>This will block any and all access, including directory - listings, to <username><replaceable>user2</replaceable></username>'s home + listings, to + <username><replaceable>user2</replaceable></username>'s home directory from the username <username>user1</username>.</para> <para>In place of <username>user1</username>, the - <option>not uid <replaceable>user2</replaceable></option> could - be passed. This will enforce the same access restrictions - above for all users in place of just one user.</para> + <option>not uid <replaceable>user2</replaceable></option> + could be passed. This will enforce the same access + restrictions above for all users in place of just one + user.</para> <note> <para>The <username>root</username> user will be unaffected - by these changes.</para> + by these changes.</para> </note> <para>This should provide a general idea of how the @@ -1007,11 +1027,11 @@ test: biba/high</screen> <para>Boot option: <literal>mac_ifoff_load="YES"</literal></para> - <para>The &man.mac.ifoff.4; module exists solely to disable network - interfaces on the fly and keep network interfaces from being - brought up during the initial system boot. It does not require - any labels to be set up on the system, nor does it have a - dependency on other <acronym>MAC</acronym> modules.</para> + <para>The &man.mac.ifoff.4; module exists solely to disable + network interfaces on the fly and keep network interfaces from + being brought up during the initial system boot. It does not + require any labels to be set up on the system, nor does it have + a dependency on other <acronym>MAC</acronym> modules.</para> <para>Most of the control is done through the <command>sysctl</command> tunables listed below.</para> @@ -1024,9 +1044,9 @@ test: biba/high</screen> </listitem> <listitem> - <para><literal>security.mac.ifoff.bpfrecv_enabled</literal> will - enable/disable all traffic on the Berkeley Packet Filter - interface (&man.bpf.4;)</para> + <para><literal>security.mac.ifoff.bpfrecv_enabled</literal> + will enable/disable all traffic on the Berkeley Packet + Filter interface (&man.bpf.4;)</para> </listitem> <listitem> @@ -1039,9 +1059,9 @@ test: biba/high</screen> monitoring in an environment where network traffic should not be permitted during the boot sequence. Another suggested use would be to write a script which uses - <filename role="package">security/aide</filename> to automatically - block network traffic if it finds new or altered files in - protected directories.</para> + <filename role="package">security/aide</filename> to + automatically block network traffic if it finds new or altered + files in protected directories.</para> </sect1> <sect1 id="mac-portacl"> @@ -1055,7 +1075,8 @@ test: biba/high</screen> <para>Kernel configuration line: <literal>MAC_PORTACL</literal></para> - <para>Boot option: <literal>mac_portacl_load="YES"</literal></para> + <para>Boot option: + <literal>mac_portacl_load="YES"</literal></para> <para>The &man.mac.portacl.4; module is used to limit binding to local <acronym>TCP</acronym> and <acronym>UDP</acronym> ports @@ -1075,14 +1096,14 @@ test: biba/high</screen> </listitem> <listitem> - <para><literal>security.mac.portacl.port_high</literal> will set - the highest port number that &man.mac.portacl.4; + <para><literal>security.mac.portacl.port_high</literal> will + set the highest port number that &man.mac.portacl.4; will enable protection for.</para> </listitem> <listitem> - <para><literal>security.mac.portacl.suser_exempt</literal> will, - when set to a non-zero value, exempt the + <para><literal>security.mac.portacl.suser_exempt</literal> + will, when set to a non-zero value, exempt the <username>root</username> user from this policy.</para> </listitem> @@ -1102,27 +1123,28 @@ test: biba/high</screen> <literal>uid</literal> or <literal>gid</literal> and used to interpret the <parameter>id</parameter> parameter as either a user id or group id, respectively. The - <parameter>protocol</parameter> parameter is used to determine if - the rule should apply to <acronym>TCP</acronym> or + <parameter>protocol</parameter> parameter is used to determine + if the rule should apply to <acronym>TCP</acronym> or <acronym>UDP</acronym> by setting the parameter to <literal>tcp</literal> or <literal>udp</literal>. The final - <parameter>port</parameter> parameter is the port number to allow - the specified user or group to bind to.</para> + <parameter>port</parameter> parameter is the port number to + allow the specified user or group to bind to.</para> <note> <para>Since the ruleset is interpreted directly by the kernel - only numeric values can be used for the user ID, group ID, and - port parameters. Names cannot be used for users, groups, or - services.</para> + only numeric values can be used for the user ID, group ID, + and port parameters. Names cannot be used for users, groups, + or services.</para> </note> <para>By default, on &unix;-like systems, ports below 1024 can only be used by/bound to privileged processes, i.e., those run as <username>root</username>. For &man.mac.portacl.4; to allow non-privileged processes to bind - to ports below 1024 this standard &unix; restriction has to be - disabled. This can be accomplished by setting the &man.sysctl.8; - variables <literal>net.inet.ip.portrange.reservedlow</literal> and + to ports below 1024 this standard &unix; restriction has to + be disabled. This can be accomplished by setting the + &man.sysctl.8; variables + <literal>net.inet.ip.portrange.reservedlow</literal> and <literal>net.inet.ip.portrange.reservedhigh</literal> to zero.</para> @@ -1162,7 +1184,7 @@ test: biba/high</screen> <screen>&prompt.root; <userinput>sysctl security.mac.portacl.rules=uid:1001:tcp:110,uid:1001:tcp:995</userinput></screen> <para>Permit the user with the <acronym>UID</acronym> of - 1001 to bind to the <acronym>TCP</acronym> ports 110 + 1001 to bind to the <acronym>TCP</acronym> ports 110 (<quote>pop3</quote>) and 995 (<quote>pop3s</quote>). This will permit this user to start a server that accepts connections on ports 110 and 995.</para> @@ -1208,8 +1230,8 @@ test: biba/high</screen> <para>When this policy is enabled, users will only be permitted to see their processes, and any others within their partition, - but will not be permitted to work with - utilities outside the scope of this partition. For instance, a user in the + but will not be permitted to work with utilities outside the + scope of this partition. For instance, a user in the <literal>insecure</literal> class above will not be permitted to access the <command>top</command> command as well as many other commands that must spawn a process.</para> @@ -1252,9 +1274,9 @@ test: biba/high</screen> <note> <para>The following policies support integer settings - in place of the three default labels offered. These options, - including their limitations, are further explained in - the module manual pages.</para> + in place of the three default labels offered. These + options, including their limitations, are further explained + in the module manual pages.</para> </note> </sect2> </sect1> @@ -1295,10 +1317,10 @@ test: biba/high</screen> <para>The <literal>mls/low</literal> label contains a low configuration which permits it to be dominated by all other objects. Anything labeled with <literal>mls/low</literal> - will have a low clearance level and not be permitted to access - information of a higher level. In addition, this label will - prevent objects of a higher clearance level from writing or - passing information on to them.</para> + will have a low clearance level and not be permitted to + access information of a higher level. In addition, this + label will prevent objects of a higher clearance level from + writing or passing information on to them.</para> </listitem> <listitem> @@ -1308,11 +1330,11 @@ test: biba/high</screen> </listitem> <listitem> - <para>The <literal>mls/high</literal> label is the highest level - of clearance possible. Objects assigned this label will *** DIFF OUTPUT TRUNCATED AT 1000 LINES ***
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201301301422.r0UEMJxB064163>