diff --git a/en_US.ISO8859-1/books/handbook/mac/chapter.sgml b/en_US.ISO8859-1/books/handbook/mac/chapter.sgml index 2133deb381..cf9e9ebb46 100644 --- a/en_US.ISO8859-1/books/handbook/mac/chapter.sgml +++ b/en_US.ISO8859-1/books/handbook/mac/chapter.sgml @@ -43,19 +43,19 @@ This chapter will focus on the Mandatory Access Control Framework (MAC Framework), and a set - of pluggable policy modules implementing various security - policies. + of pluggable security policy modules enableing various security + mechanisms. After reading this chapter, you will know: - What MAC modules are currently - included in &os; and their associated policies. + What MAC security policy modules are currently + included in &os; and their associated mechanisms. - What MAC policy modules implement as + What MAC security policy modules implement as well as the difference between a labeled and non-labeled policy. @@ -66,8 +66,8 @@ - How to configure the different policies used by the - MAC modules. + How to configure the different security policy modules included with the + MAC framework. @@ -104,7 +104,7 @@ The improper use of the - information in this chapter may cause loss of access to the system, + information in this chapter 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 @@ -116,7 +116,7 @@ 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 these policies takes + on a production system. Implementing the various security policy modules takes a good deal of thought. 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 @@ -128,13 +128,13 @@ This chapter covers a broad range of security issues relating to the MAC framework; however, the - development of new MAC policies - will not be covered. A number of modules included with the + development of new MAC security policy 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 &man.mac.test.4;, - &man.mac.stub.4; and &man.mac.none.4; modules/policies. - For more information on these modules and the various + &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. @@ -155,7 +155,7 @@ 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 - policy. + security policy. @@ -169,11 +169,11 @@ label: A label is a security attribute which can be applied to files, directories, or other items in the system. It could be considered - to be a confidentiality stamp; when a label is placed on + 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: while + 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. @@ -194,7 +194,7 @@ a new file system. This option will permit an administrator to apply different MAC labels on different objects. This option - only applies to labeled policies. + only applies to security policy modules which support labeling. @@ -252,14 +252,14 @@ With all of these new terms in mind, consider how the MAC framework augments the security of - the system as a whole. The various security policies provided by + 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 policies is to blend them together, by loading - several security policy modules at a time, for a multi-layered + 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 policies are in effect to keep security in check. This + 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 @@ -273,30 +273,30 @@ 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 policies offered by the framework. + 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 policies; and + 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 policies. Some environments + 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; policies might make good starting points. In other + &man.mac.biba.4; policy modules might make good starting points. In other cases, strict confidentiality of file system objects might - be required. Policies such as &man.mac.bsdextended.4; + be required. Policy modules such as &man.mac.bsdextended.4; and &man.mac.mls.4; exist for this purpose. 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 of choice for these situations. But what should 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 @@ -309,17 +309,17 @@ 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 policies provided by + 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 the fear of information + appropriate areas without fear of information leakage. - Thus, each policy has a unique way of dealing with - the overall security of a system. Policy selection should be based + 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 policies offered by + the system. Understanding the different security policy modules offered by the MAC framework will help administrators choose the best policies for their situations. @@ -334,10 +334,10 @@ While the various manual pages for MAC - modules state that they may be built into the kernel, + 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, but care must be taken + 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 @@ -354,8 +354,8 @@ 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 loaded, and that - policies interpret their attributes in pretty different + 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 @@ -368,18 +368,18 @@ 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 policy, + on a file will represent a label maintained by the Biba security policy module, with a value of low. - A few policies which support the labeling feature in + 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, you + 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 - policies. + policy modules. Within single label file system environments, only one label may be used on objects. This will enforce one set of @@ -402,9 +402,9 @@ Hey wait, this is similar to DAC! I thought MAC gave control strictly to the administrator. That statement still holds true, to some - extent root is the one in control and who - configures the policy so that users are placed in the - appropriate categories/access levels. Alas, many policies can + 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 @@ -414,7 +414,7 @@ Label Configuration - Virtually all aspects of label policy configuration + Virtually all aspects of label policy module configuration will be performed using the base system utilities. These commands provide a simple interface for object or subject configuration or the manipulation and verification of @@ -455,14 +455,14 @@ test: biba/high As we see above, setpmac - can be used to override the policy's settings by assigning + 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 policies, the + rules of the loaded policy modules, the Operation not permitted error will be displayed by the mac_set_link function. @@ -554,10 +554,10 @@ test: biba/high 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 that uses labels + by use of login classes. Every policy module that uses labels will implement the user class setting. - An example entry containing every policy is listed + An example entry containing every policy module setting is displayed below: default:\ @@ -589,7 +589,7 @@ test: biba/high 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. + 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. @@ -643,7 +643,7 @@ test: biba/high biba/high(low-high) the entire label should be quoted; otherwise an error will be returned. - Each policy which supports labeling has some tunable + 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 @@ -655,7 +655,7 @@ test: biba/high Singlelabel or Multilabel? - + By default the system will use the option. But what does this mean to the administrator? There are several differences