From 1a69d299f66f374318ff9d0a69f0d6ff09d04395 Mon Sep 17 00:00:00 2001 From: Dru Lavigne Date: Wed, 26 Mar 2014 15:52:52 +0000 Subject: Slight shuffling of content to improve flow of MAC chapter. Editorial review of Synopsis and Key Terms. More commits to come. Sponsored by: iXsystems --- en_US.ISO8859-1/books/handbook/mac/chapter.xml | 275 ++++++++++++------------- 1 file changed, 132 insertions(+), 143 deletions(-) (limited to 'en_US.ISO8859-1/books/handbook/mac') diff --git a/en_US.ISO8859-1/books/handbook/mac/chapter.xml b/en_US.ISO8859-1/books/handbook/mac/chapter.xml index 7c11cc6d99..a67e5f99f9 100644 --- a/en_US.ISO8859-1/books/handbook/mac/chapter.xml +++ b/en_US.ISO8859-1/books/handbook/mac/chapter.xml @@ -21,20 +21,19 @@ MAC - &os; 5.X introduced new security extensions from the - TrustedBSD - Project based on the &posix;.1e draft. Two of the - most significant new security mechanisms are file system Access - Control Lists (ACLs) and Mandatory Access - Control (MAC) facilities. MAC allows new - access control modules to be loaded, implementing new security + &os; supports security extensions + based on the &posix;.1e draft. These + security mechanisms include file system Access + Control Lists () and Mandatory Access + Control (MAC). MAC allows + access control modules to be loaded in order to implement 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 + of Discretionary Access Control (DAC) where enforcement is left to the discretion of users. This chapter focuses on the MAC framework @@ -109,28 +108,23 @@ understanding, proper design, and thorough testing. - - What Will Not Be Covered - - This chapter covers a broad range of security issues - relating to the MAC framework. The + While this chapter covers a broad range of security issues + relating to the MAC framework, 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 - &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, refer to their manual - pages. - + testing and new module development. Refer to + &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. - Key Terms in This Chapter + Key Terms - Before reading this chapter, a few key terms must be - explained: + The following key terms are used when referring to the + MAC framework: @@ -143,21 +137,18 @@ policy. - - 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 include this type of policy. - - 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. + + level: the increased or decreased + setting of a security attribute. As the level increases, + its security is considered to elevate as well. + + label: a security attribute which can be applied to files, directories, or other items in the @@ -172,24 +163,9 @@ access. - - level: the increased or decreased - setting of a security attribute. As the level increases, - its security is considered to elevate as well. - - - - 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: this property is a file - system option which can be set in single user mode using + 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 @@ -197,6 +173,14 @@ security policy modules which support labeling. + + 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. + + object: an entity through which information flows under the direction of a @@ -204,123 +188,57 @@ 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 + an object effectively means access to its data. + + 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. + + 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 considers the term - policy to be a security - policy, or a collection of rules which controls + policy usually documents how certain + items are to be handled. This chapter considers a + policy to be 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 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 - data. + 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 include this type of policy. - 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. + 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;. - 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. + 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 + data. - - Explanation of MAC - - 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 policy modules - provided by the MAC framework could be used - 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. 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. - - - 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. - - - Understanding MAC Labels @@ -735,6 +653,77 @@ test: biba/high &man.mac.bsdextended.4; policies. In the case of a machine with few local users, &man.mac.partition.4; might be a good choice. + + Consider how the + 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 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. 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. + + + 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. + -- cgit v1.2.3