diff --git a/en_US.ISO8859-1/books/handbook/mac/chapter.sgml b/en_US.ISO8859-1/books/handbook/mac/chapter.sgml index c9b626e405..1bc14a60c7 100644 --- a/en_US.ISO8859-1/books/handbook/mac/chapter.sgml +++ b/en_US.ISO8859-1/books/handbook/mac/chapter.sgml @@ -23,22 +23,25 @@ Mandatory Access Control &os; 5.X introduced new security extensions from the - TrustedBSD project based on the &posix;.1e draft. The most - important new security mechanisms are file system Access Control + 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). Mandatory Access Control allows an - administrator to enforce additional security for all subjects - (e.g. processes or sockets) and objects (e.g. sockets, file - system objects, sysctl nodes) in the system. The mandatory part + (MAC). 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, while 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 normal - access method). + discretionary access control (DAC, the standard + file and System V IPC permissions on &os;. This chapter will focus on the - Mandatory Access Control framework, hereon referred to simply as - MAC. + Mandatory Access Control Framework (MAC Framework), and a set + of pluggable policy modules implementing various security + policies. After reading this chapter, you will know: @@ -65,14 +68,14 @@ - How to implement a secure environment using the + How to implement a more secure environment using the MAC framework and the examples shown. How to test the MAC configuration - to ensure the system is properly accepting it. + to ensure the framework has been properly implemented. @@ -101,7 +104,7 @@ information in this chapter may cause loss of access to the system, aggravation of users, or inability to access the features provided by &xfree86;. More importantly, MAC should not - be relied upon to completely secure a system. The + be relied upon to 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 @@ -139,42 +142,56 @@ 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. The following terms will be used throughout - this chapter: + and information. compartment: A compartment is a a set of programs and data to be partitioned or separated, - where users are given certain access to specific components + 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. Access - to compartments is granted on a need-to-know basis. + such as a work group, department, project, or topic. Using + compartments, it is possible to implement a need-to-know + 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. label: A label is a security - feature which can be applied to files, directories, and + 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 file it describes the level of security for that specific + a file it describes the security properties for that specific file and will only permit access by files, users, resources, - etc. with a similar or lesser security setting. Some of - the policies can handle labels in different ways; this will - be discussed in the policy sections later. + etc. with a similar security setting. The meaning and + interpretation of label values depends on the policy: 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. + + + + level: The increased or decreased + setting of a security attribute. As the level increases, + its security is considered to elevate as well. multilabel: The - is a file system option + property is a file system option which can be set in single user mode using the &man.tunefs.8; utility; set during the boot operation using the &man.fstab.5; file; or during the creation of - a new file system. This option will permit multiple - MAC labels to be placed on files - and directories in the file system. This option - only applies to policies which use label operations - for enhanced security. + a new file system. This option will permit an administrator + to apply different MAC labels on different + objects. This option + only applies to policies labeled policies. @@ -194,7 +211,18 @@ policy usually documents how certain items are to be handled. This chapter will consider the term policy in this - context as a security policy. + 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. + + + + sensitivity: Usually used when + discussing MLS. A sensitivity level is + a term used to describe how important or secret the data + should be. As the sensitivity level increases, so does the + importance of the data. @@ -203,14 +231,15 @@ 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 must conform to the same label setting. + 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 processor, - system process, etc. + system process, etc. On &os;, this is almost always a thread + acting in a process on behalf of a user. @@ -224,17 +253,23 @@ 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 for - a multi-layered security environment. The only downside is + the best use of the policies is to blend them together, by loading several 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 is different + then 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. A good implementation would hand - total control over to the system administrator, who then - could control various aspects of these policies using the - &man.sysctl.8; utility. + effect of the framework; for instance, the ability to pick 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 policies offered by the framework.. Thus a system utilizing MAC features should at least guarantee that a user will not be permitted @@ -277,102 +312,106 @@ leakage. Thus, each policy has a unique way of dealing with - information flow. Policy selection should be based + the overall security of a system. Policy selection should be based on a well thought out security policy. In many cases, the - overall policy may need to be revised and reimplemented across - the network. Understanding the different policies offered by + overall policy may need to be revised and reimplemented on + the system. Understanding the different policies 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 - applying the information in this chapter to any &os; environment: + information in this chapter: options MAC And the kernel will require a rebuild and a reinstall. - + While the various manual pages for MAC modules state that they may be built into the kernel, it is possible to lock the system out of - the network and more. Therefore, this is not recommended - to those who are new the framework. - + the network and more. Implementing MAC + is much like implementing a firewall, but 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. + Understanding MAC Labels - A MAC label is a virtual security - stamp which may be applied to subjects and objects throughout + A MAC label is a security attribute + 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. Setting the label - too high or too low may jeopardize the entire security - structure of their directory or file system. + 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 + 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. - The label specifies exactly what type of access control - should be enforced on the object or subject. Formatting of - the label is simple, taking the policy name and a qualifier, - or setting, for that object or subject. + 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 give that file a basic low access control - policy. + on a file will represent a label maintained by the Biba policy, + with a value of low. - These labels are what helps to partition, or divide into - groups, several objects from each other based on their security - profile. - - With every policy which supports the labeling feature in - &os;, three specific predefined labels are offered, they + A few policies which support the labeling feature in + &os; offers 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 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. + setting available in the Biba and MLS + policies. - Within single label environments, only one label may be - used on objects and subjects. This will enforce one set of + Within single label file system environments, only one label may be + used on objects. This will enforce one set of access permissions across the entire system and in many environments may be all that is required. There are a few cases; however, where multiple labels may be set on objects - or subjects in the system. For those cases, the + or subjects in the file system. For those cases, the option may be passed to &man.tunefs.8;. - In other cases still, a numeric label may be set to + In the case of Biba and MLS, a numeric label may be set to indicate the precise level of hierarchical control. This - numeric compartment is used to partition or sort information + numeric level is used to partition or sort information into different groups of say, 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; indeed this - limits the need for the soon to be discussed - option. That option should only - be enabled if the situation requires it. + 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, - root is the one in control and who + 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. Basic control over + appropriate categories/access levels. Alas, many policies 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 discussed - earlier in this chapter. + at any time. This is the hierarchal/clearance model covered + by policies such as Biba and MLS. Label Configuration Virtually all aspects of label policy configuration - will be performed using a set of four commands. These + 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 the configuration. @@ -388,10 +427,20 @@ 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. In some cases this + 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. The system administrator + 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 because of a property of the file, a property + of the process, or a property of the proposed new label value. + For example: a user running at low integrity tries to change + the label of a high integrity file. Or perhaps a user running + at low integrity tries to change the label of a low integrity + file to a high integrity label.i The system administrator may use the following commands to overcome this: &prompt.root; setfmac biba/high test @@ -406,10 +455,9 @@ test: biba/high 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. It should be pointed - out that users will only be able to override policy labels if - they themselves own the object or subject. If users - attempt to manipulate a file not in their access levels, the + 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 Operation not permitted error will be displayed by the mac_set_link function. @@ -418,10 +466,11 @@ test: biba/high Users and Label Settings Users themselves are required to have labels so that - their files and processes may properly. This is + 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 - will enforce the user class setting. + will implement the user class setting. An example entry containing every policy is listed below: @@ -448,7 +497,7 @@ test: biba/high :passwordtime=91d:\ :umask=022:\ :ignoretime@:\ - :label=partition/13,mls/5,biba/low,lomac10[2]: + :label=partition/13,mls/5,biba/10(5-15),lomac10[2]: The label option is used to set the user class default label which will be enforced by @@ -459,6 +508,17 @@ test: biba/high It is recommended that the rest of this chapter be reviewed before any of this 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. + + In all cases, after a change to login.conf, the login class capability database must be rebuilt using cap_mkdb @@ -469,6 +529,10 @@ test: biba/high particularly large number of users requiring several different user classes. In depth planning is required as this may get extremely difficult to manage. + + Future versions of &os; will include a new way to + deal with mapping users to labels; however, this will + not be available until some time after &os; 5.3.