Date: Thu, 7 Feb 2013 15:05:37 +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: r40904 - head/en_US.ISO8859-1/books/handbook/mac Message-ID: <201302071505.r17F5bYc094277@svn.freebsd.org>
next in thread | raw e-mail | index | archive | help
Author: dru Date: Thu Feb 7 15:05:37 2013 New Revision: 40904 URL: http://svnweb.freebsd.org/changeset/doc/40904 Log: This patch addresses the following: - removes etc. and i.e. - fixes some title capitalization - fixes incorrect grammar and overuse of ; - fixes verb tense from future to active - fixes redundancy - general rewording to make a densely written dense subject slightly less dense - link added for trustedbsd website - spell out of acronyms introduced on first instance in section and used as acronym for all other instances - remove reference to trustedbsd mailing lists as these have only seen spam posts in past 6 years - reference to SEBSD was removed as does not exist - reference to deprecated lomac confusion removed - fix varname tags - note added that as of 8.x, MAC is in GENERIC 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 Thu Feb 7 15:02:30 2013 (r40903) +++ head/en_US.ISO8859-1/books/handbook/mac/chapter.xml Thu Feb 7 15:05:37 2013 (r40904) @@ -27,44 +27,42 @@ </indexterm> <para>&os; 5.X introduced new security extensions from the - TrustedBSD project based on the &posix;.1e draft. Two of the + <ulink url="http://www.trustedbsd.org">TrustedBSD + Project</ulink> 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> + Control (<acronym>MAC</acronym>) facilities. MAC allows new + access control modules to be loaded, implementing new security + policies. Some modules provide protections for 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 indicates that enforcement + of controls is performed by administrators and the operating + system. This is in contrast to the default security mechanism + of Discretionary Access Control (<acronym>DAC</acronym> where + enforcement is left to the discretion of users.</para> + + <para>This chapter focuses on the <acronym>MAC</acronym> framework + and the set of pluggable security policy modules &os; provides + for 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>Which <acronym>MAC</acronym> security policy modules + are 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>The capabilities of <acronym>MAC</acronym> security + policy modules as well as the difference between a labeled + and non-labeled policy.</para> </listitem> <listitem> - <para>How to efficiently configure a system to use - the <acronym>MAC</acronym> framework.</para> + <para>How to efficiently configure a system to use the + <acronym>MAC</acronym> framework.</para> </listitem> <listitem> @@ -74,8 +72,7 @@ <listitem> <para>How to implement a more secure environment using the - <acronym>MAC</acronym> framework and the examples - shown.</para> + <acronym>MAC</acronym> framework.</para> </listitem> <listitem> @@ -94,36 +91,27 @@ </listitem> <listitem> - <para>Be familiar with - the basics of kernel configuration/compilation - (<xref linkend="kernelconfig"/>).</para> - </listitem> - - <listitem> <para>Have some familiarity with security and how it pertains to &os; (<xref linkend="security"/>).</para> </listitem> </itemizedlist> <warning> - <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 - 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> + <para>Improper <acronym>MAC</acronym> configuration may cause + loss of system access, aggravation of users, or inability to + access the features provided by + <application>Xorg</application>. More importantly, + <acronym>MAC</acronym> should not be relied upon to completely + secure a system. The <acronym>MAC</acronym> framework only + augments an existing security policy. Without sound security + practices and regular security checks, the system will never + be completely secure.</para> + + <para>The examples contained within this chapter are for + demonstration purposes and the example settings should + <emphasis>not</emphasis> be implemented on a production + system. Implementing any security policy takes a good deal of + understanding, proper design, and thorough testing.</para> </warning> <sect2> @@ -135,10 +123,10 @@ 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 + testing and new module development. These include &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 + the various mechanisms they provide, refer to their manual pages.</para> </sect2> </sect1> @@ -147,127 +135,117 @@ <title>Key Terms in This Chapter</title> <para>Before reading this chapter, a few key terms must be - explained. This will hopefully clear up any confusion that - may occur and avoid the abrupt introduction of new terms - and information.</para> + explained:</para> <itemizedlist> <listitem> - <para><emphasis>compartment</emphasis>: A compartment is a - set of programs and data to be partitioned or separated, - where users are given explicit access to specific components - of a system. Also, a compartment represents a grouping, - such as a work group, department, project, or topic. Using - compartments, it is possible to implement a need-to-know - security policy.</para> + <para><emphasis>compartment</emphasis>: a set of programs and + data to be partitioned or separated, where users are given + explicit access to specific component of a system. A + compartment represents a grouping, such as a work group, + department, project, or topic. Compartments make it + possible to implement a need-to-know-basis security + policy.</para> </listitem> <listitem> - <para><emphasis>high water mark</emphasis>: A high water mark - policy is one which permits the raising of security levels - for the purpose of accessing higher level information. In - most cases, the original level is restored after the process + <para><emphasis>high-watermark</emphasis>: this type of + policy permits the raising of security levels 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 include this type of policy.</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> + <para><emphasis>integrity</emphasis>: 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> </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 - 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> + <para><emphasis>label</emphasis>: 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 of that file and will only permit access by + files, users, and resources with a similar security setting. + The meaning and interpretation of label values depends on + the policy configuration. Some policies treat a label as + representing the integrity or secrecy of an object while + other policies might use labels to hold rules for + access.</para> </listitem> <listitem> - <para><emphasis>level</emphasis>: The increased or decreased + <para><emphasis>level</emphasis>: the increased or decreased setting of a security attribute. As the level increases, its security is considered to elevate as well.</para> </listitem> <listitem> - <para><emphasis>low water mark</emphasis>: A low water mark - policy is one which permits lowering of the security levels - for the purpose of accessing information which is less - secure. In most cases, the original security level of the - user is restored after the process is complete. The only - security policy module in &os; to use this is - &man.mac.lomac.4;.</para> + <para><emphasis>low-watermark</emphasis>: this type of + policy permits lowering security levels for the purpose of + accessing information which is less secure. In most cases, + the original security level of the user is restored after + the process is complete. The only security policy module in + &os; to use this is &man.mac.lomac.4;.</para> </listitem> <listitem> - <para><emphasis>multilabel</emphasis>: The - <option>multilabel</option> property is a file system option - which can be set in single user mode using the - &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> + <para><emphasis>multilabel</emphasis>: this property is a file + system option which can be set in single user mode using + &man.tunefs.8;, during boot using &man.fstab.5;, or during + the creation of a new file system. This option permits + an administrator 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> + <para><emphasis>object</emphasis>: 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 or moving device. An + object is a data container or a system resource. Access to + an <emphasis>object</emphasis> effectively means access to + its data.</para> </listitem> <listitem> - <para><emphasis>policy</emphasis>: A collection of rules + <para><emphasis>policy</emphasis>: a collection of rules which defines how objectives are to be achieved. A <emphasis>policy</emphasis> usually documents how certain - items are to be handled. This chapter will - consider the term <emphasis>policy</emphasis> in this - context as a <emphasis>security policy</emphasis>; i.e. - a collection of rules which will control the flow of data - and information and define whom will have access to that - data and information.</para> + items are to be handled. This chapter considers the term + <emphasis>policy</emphasis> to be a <emphasis>security + policy</emphasis>, or a collection of rules which controls + the flow of data and information and defines who has access + to that data and information.</para> </listitem> <listitem> - <para><emphasis>sensitivity</emphasis>: Usually used when - discussing <acronym>MLS</acronym>. A sensitivity level is - a term used to describe how important or secret the data + <para><emphasis>sensitivity</emphasis>: usually used when + discussing Multilevel Security <acronym>MLS</acronym>. A + sensitivity level describes how important or secret the data should be. As the sensitivity level increases, so does the - importance of the secrecy, or confidentiality of the + importance of the secrecy, or confidentiality, of the data.</para> </listitem> <listitem> - <para><emphasis>single label</emphasis>: A single label is - when the entire file system uses one label to - enforce access control over the flow of data. When a file - system has this set, which is any time when the - <option>multilabel</option> option is not set, all - files will conform to the same label setting.</para> + <para><emphasis>single label</emphasis>: a policy where the + entire file system uses one label to enforce access control + over the flow of data. Whenever <option>multilabel</option> + is not set, all files will conform to the same label + setting.</para> </listitem> <listitem> - <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 + <para><emphasis>subject</emphasis>: any active entity that + causes information to flow between + <emphasis>objects</emphasis> such as a user, user process, + or system process. On &os;, this is almost always a thread acting in a process on behalf of a user.</para> </listitem> </itemizedlist> @@ -280,99 +258,71 @@ <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> - - <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> - - <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> - - <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> + 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 + which policies are required for a specific configuration and + which 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>A system utilizing <acronym>MAC</acronym> guarantees 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 total control of the + <acronym>MAC</acronym> access rules are 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; + 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 + modules.</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 - users? Or should we limit user or utility access to specific - files by setting certain objects as classified?</para> - - <para>In the file system case, access to objects might be - considered confidential to some users, but not to others. - For an example, a large development team might be broken - off into smaller groups of individuals. Developers in - 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 - 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 + configuration. If only certain users should be permitted + access to &man.ssh.1;, the &man.mac.portacl.4; policy module is + a good choice. In the case of file systems, access to objects + might be considered confidential to some users, but not to + others. As an example, a large development team might be + broken off into smaller projects where developers in project A + might not be permitted to access objects written by developers + in project B. Yet both projects might need to access objects + created by developers in project C. 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 objects.</para> + + <para>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 which may require + revision and reimplementation. 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 - kernel option must be added before trying any of the examples or - information in this chapter:</para> - - <programlisting>options MAC</programlisting> - - <para>And the kernel will require a rebuild and a - reinstall.</para> - <caution> - <para>While the various manual pages for <acronym>MAC</acronym> - policy modules state that they may be built into the kernel, - it is possible to lock the system out of - the network and more. Implementing <acronym>MAC</acronym> - is much like implementing a firewall, 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 while the implementation of <acronym>MAC</acronym> - remotely should be done with extreme caution.</para> + <para>Implementing <acronym>MAC</acronym> is much like + implementing a firewall, 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> remotely should be + done with extreme caution.</para> </caution> </sect1> @@ -383,65 +333,55 @@ which may be applied to subjects and objects throughout the system.</para> - <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 - system.</para> + <para>When setting a label, the administrator must be able to + comprehend what exactly is being done and understand any + implications in order to prevent unexpected or undesired + behavior of the system. The attributes available on an object + depend on the loaded policy module as policy modules interpret + their attributes in different ways.</para> <para>The security label on an object is used as a part of a security access control decision by a policy. With some - policies, the label by itself contains all information necessary - 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> + policies, the label contains all of the information necessary + to make a decision. In other policies, the labels may be + processed as part of a larger rule set. 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 - 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, - 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> + in &os; offer three specific predefined labels: low, high, and + equal. Such policy modules enforce access control in a + different manner with each policy module, where the low label is + the lowest setting, the equal label sets the subject or object + to be disabled or unaffected, and the high label enforces 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 + label may be used on objects. This label enforces 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 - <option>multilabel</option> option may be passed to + in the file system by passing <option>multilabel</option> to &man.tunefs.8;.</para> <para>In the case of Biba and <acronym>MLS</acronym>, a numeric label may be set to indicate the precise level of hierarchical control. This numeric level is used to partition or sort - information into different groups of say, classification only + information into different groups of classification only permitting access to that group or a higher group level.</para> - <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 + <para>In most cases, the administrator will set up a single label + to use throughout the file system. This is similar to + <acronym>DAC</acronym> 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 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 + at any time. This is the hierarchical/clearance model covered by policies such as Biba and <acronym>MLS</acronym>.</para> <sect2> @@ -453,32 +393,29 @@ configuration or the manipulation and verification of the configuration.</para> - <para>All configuration may be done by use of the - &man.setfmac.8; and &man.setpmac.8; utilities. - The <command>setfmac</command> command is used to set - <acronym>MAC</acronym> labels on system objects while the - <command>setpmac</command> command is used to set the labels - on system subjects. Observe:</para> + <para>All configuration may be done using &man.setfmac.8; and + &man.setpmac.8;. <command>setfmac</command> is used to set + <acronym>MAC</acronym> labels on system objects while + <command>setpmac</command> is used to set the labels on system + subjects. Observe:</para> <screen>&prompt.root; <userinput>setfmac biba/high test</userinput></screen> - <para>If no errors occurred with the command above, a prompt - will be returned. The only time these commands are not - quiescent is when an error occurred; similarly to the - &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 + <para>If the configuration is successful, the prompt will be + returned without error. A common error is + <errorname>Permission denied</errorname> which usually occurs + when the label is being set or modified 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 the object 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 + 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 + integrity file to a high integrity label.</footnote> The system administrator may use the following commands to overcome this:</para> @@ -488,18 +425,16 @@ &prompt.root; <userinput>getfmac test</userinput> 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 - will be displayed by the <function>mac_set_link</function> - function.</para> + <para><command>setpmac</command> can be used to override the + policy module's settings by assigning a different label to the + invoked process. <command>getpmac</command> is usually used + with currently running processes, such as + <application>sendmail</application>. It takes a process ID in + place of a command. 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> <sect3> <title>Common Label Types</title> @@ -507,15 +442,14 @@ test: biba/high</screen> <para>For the &man.mac.biba.4;, &man.mac.mls.4; and &man.mac.lomac.4; policy modules, the ability to assign simple labels is provided. These take the form of high, - equal and low, what follows is a brief description of - what these labels provide:</para> + equal, and low, where:</para> <itemizedlist> <listitem> <para>The <literal>low</literal> label is considered the lowest label setting an object or subject may have. - Setting this on objects or subjects will block their - access to objects or subjects marked high.</para> + Setting this on objects or subjects blocks their access + to objects or subjects marked high.</para> </listitem> <listitem> @@ -531,66 +465,62 @@ test: biba/high</screen> </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 + settings will establish a different information flow + directive. Refer to the manual pages of the module to + determine the traits of these generic label configurations.</para> <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>. + For example:</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 + <para>may be interpreted as <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 the <quote>effective grade</quote> with <quote>effective compartments</quote>, the second grade - is the low grade and the last one is the high grade. - In most configurations these settings will not be used; - indeed, they offered for more advanced - configurations.</para> - - <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> + is the low grade, and the last one is the high grade. + In most configurations, these settings will not be used + as they are advanced configurations.</para> + + <para>System objects only have a current grade/compartment. + System subjects 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 + pair are used to construct a relationship known 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, - <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> + Biba, a user has rights to a set of compartments 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> </sect4> </sect3> <sect3> <title>Users and Label Settings</title> - <para>Users themselves are required to have labels so that - 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> + <para>Users are required to have labels so that their files + and processes properly interact with the security policy + defined on the system. This is configured in + <filename>login.conf</filename> using 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> @@ -619,49 +549,49 @@ test: biba/high</screen> :ignoretime@:\ :label=partition/13,mls/5,biba/10(5-15),lomac/10[2]:</programlisting> - <para>The <literal>label</literal> option is used to set the + <para>To set the user class default label which will be enforced by - <acronym>MAC</acronym>. Users will never be permitted to - modify this value, thus it can be considered not optional - in the user case. In a real configuration, however, the - administrator will never wish to enable every policy module. - It is recommended that the rest of this chapter be reviewed - before any of this configuration is implemented.</para> + <acronym>MAC</acronym>, use <option>label</option>. Users + are never permitted to modify this value. In a real + configuration, however, the administrator would never enable + every policy module. It is recommended that the rest of + this chapter be reviewed before any configuration is + implemented.</para> <note> - <para>Users may change their label after the initial login; - however, this change is subject constraints of the policy. - The example above tells the Biba policy that a process's - minimum integrity is 5, its maximum is 15, but the default - effective label is 10. The process will run at 10 until - it chooses to change label, perhaps due to the user using - the setpmac command, which will be constrained by Biba to - the range set at login.</para> + <para>Users may change their label after they login, subject + to the constraints of the policy. The example above tells + the Biba policy that a process's minimum integrity is 5, + its maximum is 15, and the default effective label is 10. + The process will run at 10 until it chooses to change + label, perhaps due to the user using &man.setpmac.8;, + which will be constrained by Biba to the configured + range.</para> </note> - <para>In all cases, after a change to + <para>After any change to <filename>login.conf</filename>, the login class capability - database must be rebuilt using <command>cap_mkdb</command> - and this will be reflected throughout every forthcoming - example or discussion.</para> - - <para>It is useful to note that many sites may have a - particularly large number of users requiring several - different user classes. In depth planning is required - as this may get extremely difficult to manage.</para> + database must be rebuilt using + <command>cap_mkdb</command>.</para> + + <para>Many sites have a large number of users requiring + several different user classes. In depth planning is + required as this may get extremely difficult to + manage.</para> </sect3> <sect3> <title>Network Interfaces and Label Settings</title> - <para>Labels may also be set on network interfaces to help - control the flow of data across the network. In all cases - they function in the same way the policies function with - respect to objects. Users at high settings in - <literal>biba</literal>, for example, will not be permitted - to access network interfaces with a label of low.</para> + <para>Labels may be set on network interfaces to help + control the flow of data across the network. Policies + using network interface labels function in the same way that + policies function with respect to objects. Users at high + settings in <literal>biba</literal>, for example, will not + be permitted to access network interfaces with a label of + low.</para> - <para>The <option>maclabel</option> may be passed to + <para><option>maclabel</option> may be passed to <command>ifconfig</command> when setting the <acronym>MAC</acronym> label on network interfaces. For example:</para> @@ -671,51 +601,44 @@ 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 + <literal>biba/high(low-high)</literal>, the entire label + should be quoted to prevent an error from being returned.</para> <para>Each policy module which supports labeling has a tunable which may be used to disable the <acronym>MAC</acronym> label on network interfaces. Setting the label to <option>equal</option> will have a similar effect. Review - the output from <command>sysctl</command>, the policy manual - pages, or even the information found later in this chapter - for those tunables.</para> + the output of <command>sysctl</command>, the policy manual + pages, and the information in this chapter for more + information on those tunables.</para> </sect3> </sect2> <sect2> <title>Singlelabel or Multilabel?</title> - <para>By default the system will use the - <option>singlelabel</option> option. But what does this - mean to the administrator? There are several differences - which, in their own right, offer pros and cons to the - flexibility in the systems security model.</para> - - <para>The <option>singlelabel</option> only permits for one - label, for instance <literal>biba/high</literal> to be used - for each subject or object. It provides for lower - administration overhead but decreases the flexibility of - policies which support labeling. Many administrators may - want to use the <option>multilabel</option> option in - their security policy.</para> - - <para>The <option>multilabel</option> option will permit each - subject or object to have its own independent - <acronym>MAC</acronym> label in - place of the standard <option>singlelabel</option> option - which will allow only one label throughout the partition. - The <option>multilabel</option> and <option>single</option> - label options are only required for the policies which - implement the labeling feature, including the Biba, Lomac, - <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 - security model:</para> + <para>By default, the system will use + <option>singlelabel</option>. For the administrator, there + are several differences which offer pros and cons to the + flexibility in the system's security model.</para> + + <para>A security policy which uses <option>singlelabel</option> + only permits one label, such as <literal>biba/high</literal>, + to be used for each subject or object. This provides lower + administration overhead, but decreases the flexibility of + policies which support labeling.</para> + + <para><option>multilabel</option> permits each subject or object + to have its own independent <acronym>MAC</acronym> label. + The decision to use <option>multilabel</option> or + <option>singlelabel</option> is only required for the policies + which implement the labeling feature, including the Biba, + Lomac, and <acronym>MLS</acronym> policies.</para> + + <para>In many cases, <option>multilabel</option> may not be + needed. Consider the following situation and security + model:</para> <itemizedlist> <listitem> @@ -726,49 +649,41 @@ 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 - <option>multilabel</option> option as a single label - will always be in effect.</para> + system. This file system would not require + <option>multilabel</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> + to prevent write up capabilities. The server could + use a separate partition set at + <literal>biba/low</literal> for most if not all + of its runtime state.</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> - - <para>It should also be noted that using - <option>multilabel</option> with a partition and establishing - a security model based on <option>multilabel</option> - functionality could open the doors for higher administrative - overhead as everything in the file system would have a label. - This includes directories, files, and even device + <option>multilabel</option> would not be required. These + include the <literal>seeotheruids</literal>, + <literal>portacl</literal> and <literal>partition</literal> + policies.</para> + + <para>Using <option>multilabel</option> with a partition and + establishing a security model based on + <option>multilabel</option> functionality could increase + administrative overhead as everything in the file system has a + label. This includes directories, files, and even device nodes.</para> <para>The following command will set <option>multilabel</option> on the file systems to have multiple labels. This may only be - done in single user mode:</para> + done in single user mode and is not a requirement for the swap *** DIFF OUTPUT TRUNCATED AT 1000 LINES ***
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201302071505.r17F5bYc094277>