From owner-svn-doc-all@FreeBSD.ORG Thu Feb 7 15:05:38 2013 Return-Path: Delivered-To: svn-doc-all@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0FECB593; Thu, 7 Feb 2013 15:05:38 +0000 (UTC) (envelope-from dru@FreeBSD.org) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) by mx1.freebsd.org (Postfix) with ESMTP id 01ED466D; Thu, 7 Feb 2013 15:05:38 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.5/8.14.5) with ESMTP id r17F5bf0094278; Thu, 7 Feb 2013 15:05:37 GMT (envelope-from dru@svn.freebsd.org) Received: (from dru@localhost) by svn.freebsd.org (8.14.5/8.14.5/Submit) id r17F5bYc094277; Thu, 7 Feb 2013 15:05:37 GMT (envelope-from dru@svn.freebsd.org) Message-Id: <201302071505.r17F5bYc094277@svn.freebsd.org> From: Dru Lavigne Date: Thu, 7 Feb 2013 15:05:37 +0000 (UTC) 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 X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-all@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "SVN commit messages for the entire doc trees \(except for " user" , " projects" , and " translations" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2013 15:05:38 -0000 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 @@ &os; 5.X introduced new security extensions from the - TrustedBSD project based on the &posix;.1e draft. Two of the + TrustedBSD + Project based on the &posix;.1e draft. Two of the most significant new security mechanisms are file system Access Control Lists (ACLs) and Mandatory Access - Control (MAC) 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 (DAC, the standard file and System - V IPC permissions on &os;). - - This chapter will focus on the - Mandatory Access Control Framework (MAC - Framework), and a set of pluggable security policy modules - enabling various security mechanisms. + Control (MAC) 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 (DAC where + enforcement is left to the discretion of users. + + This chapter focuses on the MAC framework + and the set of pluggable security policy modules &os; provides + for enabling various security mechanisms. After reading this chapter, you will know: - What MAC security policy modules - are currently included in &os; and their associated - mechanisms. + Which MAC security policy modules + are included in &os; and their associated mechanisms. - What MAC security policy modules - implement as well as the difference between a labeled and - non-labeled policy. + The capabilities of MAC security + policy modules as well as the difference between a labeled + and non-labeled policy. - How to efficiently configure a system to use - the MAC framework. + How to efficiently configure a system to use the + MAC framework. @@ -74,8 +72,7 @@ How to implement a more secure environment using the - MAC framework and the examples - shown. + MAC framework. @@ -94,36 +91,27 @@ - Be familiar with - the basics of kernel configuration/compilation - (). - - - Have some familiarity with security and how it pertains to &os; (). - 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, MAC - should not be relied upon to completely secure a system. The - MAC framework only augments existing - security policy; without sound security practices and - regular security checks, the system will never be completely - secure. - - 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. + Improper MAC configuration may cause + loss of system access, aggravation of users, or inability to + access the features provided by + Xorg. More importantly, + MAC should not be relied upon to completely + secure a system. The MAC framework only + augments an existing security policy. Without sound security + practices and regular security checks, the system will never + be completely secure. + + The examples contained within this chapter are for + demonstration purposes and the example settings should + not be implemented on a production + system. Implementing any security policy takes a good deal of + understanding, proper design, and thorough testing. @@ -135,10 +123,10 @@ modules will not be covered. A number of security policy modules included with the MAC 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. @@ -147,127 +135,117 @@ Key Terms in This Chapter 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. + explained: - compartment: 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. + compartment: 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. - high water mark: 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 + high-watermark: 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; MAC - framework does not have a policy for this, but the - definition is included for completeness. + framework does not include this type of policy. - integrity: 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. + integrity: 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. - label: 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. + label: 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. - level: The increased or decreased + level: the increased or decreased setting of a security attribute. As the level increases, its security is considered to elevate as well. - low water mark: 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;. + low-watermark: 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;. - multilabel: The - 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 MAC labels on - different objects. This option only applies to security - policy modules which support labeling. + multilabel: 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 MAC + labels on different objects. This option only applies to + security policy modules which support labeling. - object: An object or system - object is an entity through which information flows - under the direction of a subject. - 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 - object effectively means access to the - data. + object: an entity through which + information flows under the direction of a + subject. 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 object effectively means access to + its data. - policy: A collection of rules + policy: a collection of rules which defines how objectives are to be achieved. A policy usually documents how certain - items are to be handled. This chapter will - consider the term policy in this - context as a security policy; 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. + items are to be handled. This chapter considers the term + policy to be a security + policy, or a collection of rules which controls + the flow of data and information and defines who has access + to that data and information. - sensitivity: Usually used when - discussing MLS. A sensitivity level is - a term used to describe how important or secret the data + sensitivity: usually used when + discussing Multilevel Security MLS. 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. - single label: 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 is not set, all - files will conform to the same label setting. + single label: a policy where the + entire file system uses one label to enforce access control + over the flow of data. Whenever + is not set, all files will conform to the same label + setting. - subject: a subject is any - active entity that causes information to flow between - objects; e.g., a user, user process, - system process, etc. On &os;, this is almost always a + subject: any active entity that + causes information to flow between + objects 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. @@ -280,99 +258,71 @@ MAC framework augments the security of the system as a whole. The various security policy modules provided by the MAC framework could be used - to protect the network and file systems, 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. - - 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. - - Thus a system utilizing MAC 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 MAC - access rules are in the hands of the system - administrator. - - 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. + to protect the network and file systems or to block users from + accessing certain ports and sockets. Perhaps the best use of + the policy modules is to load several security policy modules at + a time in order to provide a MLS environment. + This approach differs from a hardening policy, which typically + hardens elements of a system which are used only for specific + purposes. The downside to MLS is increased + administrative overhead. + + The overhead is minimal when compared to the lasting effect + of a framework which provides the ability to pick and choose + 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. + + A system utilizing MAC 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 + MAC access rules are in the hands of the + system administrator. + + It is the duty of the system administrator to + carefully select the correct security policy modules. For an + environment that needs to limit access control over the network, + the &man.mac.portacl.4;, &man.mac.ifoff.4;, and &man.mac.biba.4; + 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. 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? - - 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 MAC framework; users could - be divided into these groups and then given access to the - appropriate areas without fear of information - leakage. - - 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 MAC + framework, users could be divided into these groups and then + given access to the appropriate objects. + + 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 MAC framework will help administrators choose the best policies for their situations. - The default &os; kernel does not include the option for - the MAC framework; thus the following - kernel option must be added before trying any of the examples or - information in this chapter: - - options MAC - - And the kernel will require a rebuild and a - reinstall. - - While the various manual pages for MAC - 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 MAC - 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 MAC - remotely should be done with extreme caution. + Implementing MAC 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 MAC remotely should be + done with extreme caution. @@ -383,65 +333,55 @@ which may be applied to subjects and objects throughout the system. - 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. + 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. 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. - - For instance, setting the label of - biba/low on a file will represent a label - maintained by the Biba security policy module, with a value - of low. + 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 biba/low on a file will + represent a label maintained by the Biba security policy module, + with a value of low. 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 MLS + 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 MLS policy modules. 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 may be passed to + in the file system by passing to &man.tunefs.8;. In the case of Biba and MLS, 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. - In most cases the administrator will only be setting up a - single label to use throughout the file system. - - Hey wait, this is similar to - DAC! I thought MAC gave - control strictly to the administrator. That - statement still holds true, to some extent as + In most cases, the administrator will set up a single label + to use throughout the file system. This is similar to + DAC to some extent as root 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 root user as well. Basic control over objects will then be released to the group, but root 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 MLS. @@ -453,32 +393,29 @@ configuration or the manipulation and verification of the configuration. - All configuration may be done by use of the - &man.setfmac.8; and &man.setpmac.8; utilities. - The setfmac command is used to set - MAC labels on system objects while the - setpmac command is used to set the labels - on system subjects. Observe: + All configuration may be done using &man.setfmac.8; and + &man.setpmac.8;. setfmac is used to set + MAC labels on system objects while + setpmac is used to set the labels on system + subjects. Observe: &prompt.root; setfmac biba/high test - 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 Permission denied and - is usually obtained when the label is being set or modified - on an object which is restricted.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 + If the configuration is successful, the prompt will be + returned without error. A common error is + Permission denied which usually occurs + when the label is being set or modified on an object which is + restricted.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. The + integrity file to a high integrity label. The system administrator may use the following commands to overcome this: @@ -488,18 +425,16 @@ &prompt.root; getfmac test test: biba/high - As we see above, setpmac - can be used to override the policy module's settings by - assigning a different label to the invoked process. The - getpmac utility is usually used with - currently running processes, such as - sendmail: 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 Operation not permitted error - will be displayed by the mac_set_link - function. + setpmac can be used to override the + policy module's settings by assigning a different label to the + invoked process. getpmac is usually used + with currently running processes, such as + sendmail. 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 Operation not permitted + error will be displayed by the + mac_set_link function. Common Label Types @@ -507,15 +442,14 @@ test: biba/high 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: + equal, and low, where: The low 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. + Setting this on objects or subjects blocks their access + to objects or subjects marked high. @@ -531,66 +465,62 @@ test: biba/high 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. Advanced Label Configuration Numeric grade labels are used for - comparison:compartment+compartment; - thus the following: + comparison:compartment+compartment. + For example: biba/10:2+3+6(5:2+3-20:2+3+4+5+6) - May be interpreted as: - - Biba Policy Label/Grade + may be interpreted as Biba Policy + Label/Grade 10:Compartments 2, 3 and 6: (grade 5 ...) In this example, the first grade would be considered the effective grade with effective compartments, 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. - - 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. + 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. + + 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. 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 dominance, in which a subject dominates an object, the object dominates the subject, neither dominates the other, or both dominate each other. The both dominate case occurs when the two labels are equal. Due to the information flow nature of - Biba, you have rights to a set of compartments, - need to know, that might correspond to - projects, but objects also have a set of compartments. - Users may have to subset their rights using - su or setpmac in - order to access objects in a compartment from which they - are not restricted. + 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 su or setpmac + in order to access objects in a compartment from which + they are not restricted. Users and Label Settings - 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 login.conf file - by use of login classes. Every policy module that uses - labels will implement the user class setting. + 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 + login.conf using login classes. Every + policy module that uses labels will implement the user class + setting. An example entry containing every policy module setting is displayed below: @@ -619,49 +549,49 @@ test: biba/high :ignoretime@:\ :label=partition/13,mls/5,biba/10(5-15),lomac/10[2]: - The label option is used to set the + To set the user class default label which will be enforced by - MAC. 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. + MAC, use . 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. - 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. + 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. - In all cases, after a change to + After any change to login.conf, the login class capability - database must be rebuilt using cap_mkdb - and this will be reflected throughout every forthcoming - example or discussion. - - 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. + database must be rebuilt using + cap_mkdb. + + 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. Network Interfaces and Label Settings - 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 - biba, for example, will not be permitted - to access network interfaces with a label of low. + 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 biba, for example, will not + be permitted to access network interfaces with a label of + low. - The may be passed to + may be passed to ifconfig when setting the MAC label on network interfaces. For example: @@ -671,51 +601,44 @@ test: biba/high will set the MAC label of biba/equal on the &man.bge.4; interface. When using a setting similar to - biba/high(low-high) the entire label - should be quoted; otherwise an error will be + biba/high(low-high), the entire label + should be quoted to prevent an error from being returned. Each policy module which supports labeling has a tunable which may be used to disable the MAC label on network interfaces. Setting the label to will have a similar effect. Review - the output from sysctl, the policy manual - pages, or even the information found later in this chapter - for those tunables. + the output of sysctl, the policy manual + pages, and the information in this chapter for more + information on those tunables. Singlelabel or Multilabel? - By default the system will use the - 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. - - The only permits for one - label, for instance biba/high 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 in - their security policy. - - The option will permit each - subject or object to have its own independent - MAC label in - place of the standard option - which will allow only one label throughout the partition. - The and - label options are only required for the policies which - implement the labeling feature, including the Biba, Lomac, - MLS and SEBSD - policies. - - In many cases, the may not - need to be set at all. Consider the following situation and - security model: + By default, the system will use + . For the administrator, there + are several differences which offer pros and cons to the + flexibility in the system's security model. + + A security policy which uses + only permits one label, such as biba/high, + to be used for each subject or object. This provides lower + administration overhead, but decreases the flexibility of + policies which support labeling. + + permits each subject or object + to have its own independent MAC label. + The decision to use or + is only required for the policies + which implement the labeling feature, including the Biba, + Lomac, and MLS policies. + + In many cases, may not be + needed. Consider the following situation and security + model: @@ -726,49 +649,41 @@ test: biba/high This machine only requires one label, biba/high, for everything in the - system. Here the file system would not require the - option as a single label - will always be in effect. + system. This file system would not require + as a single label will always + be in effect. But, this machine will be a web server and should have the web server run at biba/low - 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 biba/low 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. + to prevent write up capabilities. The server could + use a separate partition set at + biba/low for most if not all + of its runtime state. If any of the non-labeling policies are to be used, - then the option would never - be required. These include the - seeotheruids, portacl - and partition policies. - - It should also be noted that using - with a partition and establishing - a security model based on - 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 + would not be required. These + include the seeotheruids, + portacl and partition + policies. + + Using with a partition and + establishing a security model based on + functionality could increase + administrative overhead as everything in the file system has a + label. This includes directories, files, and even device nodes. The following command will set on the file systems to have multiple labels. This may only be - done in single user mode: + done in single user mode and is not a requirement for the swap *** DIFF OUTPUT TRUNCATED AT 1000 LINES ***