From b4346b9b2dfe86a97907573086dff096850dcb1d Mon Sep 17 00:00:00 2001 From: Gabor Kovesdan Date: Mon, 1 Oct 2012 09:53:01 +0000 Subject: - Rename .sgml files to .xml - Reflect the rename in referencing files Approved by: doceng (implicit) --- en_US.ISO8859-1/books/handbook/mac/Makefile | 2 +- en_US.ISO8859-1/books/handbook/mac/chapter.sgml | 2075 ----------------------- en_US.ISO8859-1/books/handbook/mac/chapter.xml | 2075 +++++++++++++++++++++++ 3 files changed, 2076 insertions(+), 2076 deletions(-) delete mode 100644 en_US.ISO8859-1/books/handbook/mac/chapter.sgml create mode 100644 en_US.ISO8859-1/books/handbook/mac/chapter.xml (limited to 'en_US.ISO8859-1/books/handbook/mac') diff --git a/en_US.ISO8859-1/books/handbook/mac/Makefile b/en_US.ISO8859-1/books/handbook/mac/Makefile index 74aca4172f..ecd40cd7e2 100644 --- a/en_US.ISO8859-1/books/handbook/mac/Makefile +++ b/en_US.ISO8859-1/books/handbook/mac/Makefile @@ -4,7 +4,7 @@ # $FreeBSD$ # -CHAPTERS= mac/chapter.sgml +CHAPTERS= mac/chapter.xml VPATH= .. diff --git a/en_US.ISO8859-1/books/handbook/mac/chapter.sgml b/en_US.ISO8859-1/books/handbook/mac/chapter.sgml deleted file mode 100644 index f94e9d5aa1..0000000000 --- a/en_US.ISO8859-1/books/handbook/mac/chapter.sgml +++ /dev/null @@ -1,2075 +0,0 @@ - - - - - - - - Tom - Rhodes - Written by - - - - - Mandatory Access Control - - - Synopsis - - MAC - - Mandatory Access Control - 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. 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. - - After reading this chapter, you will know: - - - - What MAC security policy modules are currently - 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. - - - - How to efficiently configure a system to use - the MAC framework. - - - - How to configure the different security policy modules included with the - MAC framework. - - - - How to implement a more secure environment using the - MAC framework and the examples - shown. - - - - How to test the MAC configuration - to ensure the framework has been properly implemented. - - - - Before reading this chapter, you should: - - - - Understand &unix; and &os; basics - (). - - - - 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. - - - - What Will Not Be Covered - - 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 the &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 pages. - - - - - 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. - - - - 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. - - - - 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 - is complete. Currently, the &os; MAC - framework does not have a policy for this, but the definition - is included for completeness. - - - - 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 - 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. - - - - 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;. - - - - 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. - - - - 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. - - - - 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. - - - - 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 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. - - - - 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 thread - acting in a process on behalf of a user. - - - - - - 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, 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. - - 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 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. - - - - - Understanding MAC Labels - - 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. 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. - - 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. - - 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 - policy modules. - - 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 where multiple labels may be set on objects - or subjects in the file system. For those cases, the - option may be passed 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 - 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 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 - by policies such as Biba and MLS. - - - Label 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 - 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: - - &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 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. The system administrator - may use the following commands to overcome this: - - &prompt.root; setfmac biba/high test -Permission denied -&prompt.root; setpmac biba/low setfmac biba/high test -&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. - - - Common Label Types - - 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: - - - - 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. - - - - The equal label should only be - placed on objects considered to be exempt from the - policy. - - - - The high label grants an object or - subject the highest possible setting. - - - - 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 configurations. - - - Advanced Label Configuration - - Numeric grade labels are used for - comparison:compartment+compartment; thus - the following: - - biba/10:2+3+6(5:2+3-20:2+3+4+5+6) - - 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. - - The grade and compartments in a subject and object pair - are used to construct a relationship referred to 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. - - - - - 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. - - An example entry containing every policy module setting is displayed - below: - - default:\ - :copyright=/etc/COPYRIGHT:\ - :welcome=/etc/motd:\ - :setenv=MAIL=/var/mail/$,BLOCKSIZE=K:\ - :path=~/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:\ - :manpath=/usr/share/man /usr/local/man:\ - :nologin=/usr/sbin/nologin:\ - :cputime=1h30m:\ - :datasize=8M:\ - :vmemoryuse=100M:\ - :stacksize=2M:\ - :memorylocked=4M:\ - :memoryuse=8M:\ - :filesize=8M:\ - :coredumpsize=8M:\ - :openfiles=24:\ - :maxproc=32:\ - :priority=0:\ - :requirehome:\ - :passwordtime=91d:\ - :umask=022:\ - :ignoretime@:\ - :label=partition/13,mls/5,biba/10(5-15),lomac/10[2]: - - The label option is used 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. - - - 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 - 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. - - - - 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. - - The may be passed to - ifconfig when setting the - MAC label on network interfaces. For - example: - - &prompt.root; ifconfig bge0 maclabel biba/equal - - 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 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. - - - - - 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: - - - - &os; web-server using the MAC - framework and a mix of the various policies. - - - - 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. - - - - 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. - - - - 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 - nodes. - - The following command will set - on the file systems to have multiple labels. This may only be - done in single user mode: - - &prompt.root; tunefs -l enable / - - This is not a requirement for the swap file - system. - - - Some users have experienced problems with setting the - flag on the root partition. - If this is the case, please review the - of this chapter. - - - - - - Planning the Security Configuration - - Whenever a new technology is implemented, a planning phase is - always a good idea. During the planning stages, an administrator - should in general look at the big picture, trying - to keep in view at least the following: - - - - The implementation requirements; - - - - The implementation goals; - - - - For MAC installations, these include: - - - - How to classify information and resources available on - the target systems. - - - - What sorts of information or resources to restrict - access to along with the type of restrictions that should be - applied. - - - - Which MAC module or modules will be - required to achieve this goal. - - - - It is always possible to reconfigure and change the - system resources and security settings, it is quite often very inconvenient to - search through the system and fix existing files and user - accounts. Planning helps to ensure a trouble-free and efficient - trusted system implementation. A trial run of the trusted system, - including the configuration, is often vital and definitely - beneficial before a MAC - implementation is used on production systems. The idea of just - letting loose on a system - with MAC is like setting up for failure. - - Different environments may have explicit needs and - requirements. Establishing an in depth and complete security - profile will decrease the need of changes once the system - goes live. As such, the future sections will cover the - different modules available to administrators; describe their - use and configuration; and in some cases provide insight on - what situations they would be most suitable for. For instance, - a web server might roll out the &man.mac.biba.4; and - &man.mac.bsdextended.4; policies. In other cases, a machine - with very few local users, the &man.mac.partition.4; might - be a good choice. - - - - Module Configuration - - Every module included with the MAC - framework may be either compiled into the kernel as noted above - or loaded as a run-time kernel module. - The recommended method is to add the module name to the - /boot/loader.conf file so that it will load - during the initial boot operation. - - The following sections will discuss the various - MAC modules and cover their features. - Implementing them into a specific environment will also - be a consideration of this chapter. Some modules support - the use of labeling, which is controlling access by enforcing - a label such as this is allowed and this is not. - A label configuration file may control how files may be accessed, - network communication can be exchanged, and more. The previous - section showed how the flag could - be set on file systems to enable per-file or per-partition - access control. - - A single label configuration would enforce only one label - across the system, that is why the tunefs - option is called . - - - - The MAC seeotheruids Module - - - MAC See Other UIDs Policy - - Module name: mac_seeotheruids.ko - - Kernel configuration line: - options MAC_SEEOTHERUIDS - - Boot option: - mac_seeotheruids_load="YES" - - The &man.mac.seeotheruids.4; module mimics and extends - the security.bsd.see_other_uids and - security.bsd.see_other_gids - sysctl tunables. This option does - not require any labels to be set before configuration and - can operate transparently with the other modules. - - After loading the module, the following - sysctl tunables may be used to control - the features: - - - - security.mac.seeotheruids.enabled - will enable the module's features and use the default - settings. These default settings will deny users the - ability to view processes and sockets owned by other - users. - - - - - security.mac.seeotheruids.specificgid_enabled - will allow a certain group to be exempt from this policy. - To exempt specific groups from this policy, use the - security.mac.seeotheruids.specificgid=XXX - sysctl tunable. In the above example, - the XXX should be replaced with the - numeric group ID to be exempted. - - - - - security.mac.seeotheruids.primarygroup_enabled - is used to exempt specific primary groups from this policy. - When using this tunable, the - security.mac.seeotheruids.specificgid_enabled - may not be set. - - - - - - The MAC bsdextended Module - - - MAC - File System Firewall Policy - - Module name: mac_bsdextended.ko - - Kernel configuration line: - options MAC_BSDEXTENDED - - Boot option: - mac_bsdextended_load="YES" - - The &man.mac.bsdextended.4; module enforces the file system - firewall. This module's policy provides an extension to the - standard file system permissions model, permitting an - administrator to create a firewall-like ruleset to protect files, - utilities, and directories in the file system hierarchy. When - access to a file system object is attempted, the list of rules - is iterated until either a matching rule is located or the end - is reached. This behavior may be changed by the use of a - &man.sysctl.8; parameter, - security.mac.bsdextended.firstmatch_enabled. Similar to - other firewall modules in &os;, a file containing access control - rules can be created and read by the system at boot time using - an &man.rc.conf.5; variable. - - The rule list may be entered using a utility, &man.ugidfw.8;, - that has a syntax similar to that of &man.ipfw.8;. More tools - can be written by using the functions in the - &man.libugidfw.3; library. - - Extreme caution should be taken when working with this - module; incorrect use could block access to certain parts of - the file system. - - - Examples - - After the &man.mac.bsdextended.4; module has - been loaded, the following command may be used to list the - current rule configuration: - - &prompt.root; ugidfw list -0 slots, 0 rules - - As expected, there are no rules defined. This means that - everything is still completely accessible. To create a rule - which will block all access by users but leave - root unaffected, simply run the - following command: - - &prompt.root; ugidfw add subject not uid root new object not uid root mode n - - This is a very bad idea as it will block all users from - issuing even the most simple commands, such as - ls. A more patriotic list of rules - might be: - - &prompt.root; ugidfw set 2 subject uid user1 object uid user2 mode n -&prompt.root; ugidfw set 3 subject uid user1 object gid user2 mode n - - This will block any and all access, including directory - listings, to user2's home - directory from the username user1. - - In place of user1, the - could - be passed. This will enforce the same access restrictions - above for all users in place of just one user. - - - The root user will be unaffected - by these changes. - - - This should provide a general idea of how the - &man.mac.bsdextended.4; module may be used to help fortify - a file system. For more information, see the - &man.mac.bsdextended.4; and the &man.ugidfw.8; manual - pages. - - - - - The MAC ifoff Module - - - MAC Interface Silencing Policy - - Module name: mac_ifoff.ko - - Kernel configuration line: - options MAC_IFOFF - - Boot option: mac_ifoff_load="YES" - - The &man.mac.ifoff.4; module exists solely to disable network - interfaces on the fly and keep network interfaces from being - brought up during the initial system boot. It does not require - any labels to be set up on the system, nor does it have a - dependency on other MAC modules. - - Most of the control is done through the - sysctl tunables listed below. - - - - security.mac.ifoff.lo_enabled will - enable/disable all traffic on the loopback (&man.lo.4;) - interface. - - - - security.mac.ifoff.bpfrecv_enabled will - enable/disable all traffic on the Berkeley Packet Filter - interface (&man.bpf.4;) - - - - security.mac.ifoff.other_enabled will - enable/disable traffic on all other interfaces. - - - - One of the most common uses of &man.mac.ifoff.4; is network - monitoring in an environment where network traffic should not - be permitted during the boot sequence. Another suggested use - would be to write a script which uses - security/aide to automatically - block network traffic if it finds new or altered files in - protected directories. - - - - The MAC portacl Module - - - MAC Port Access Control List Policy - - Module name: mac_portacl.ko - - Kernel configuration line: - MAC_PORTACL - - Boot option: mac_portacl_load="YES" - - The &man.mac.portacl.4; module is used to limit binding to - local TCP and UDP ports - using a variety of sysctl variables. In - essence &man.mac.portacl.4; makes it possible to allow - non-root users to bind to specified - privileged ports, i.e., ports below 1024. - - Once loaded, this module will enable the - MAC policy on all sockets. The following - tunables are available: - - - - security.mac.portacl.enabled will - enable/disable the policy completely. - - - - security.mac.portacl.port_high will set - the highest port number that &man.mac.portacl.4; - will enable protection for. - - - - security.mac.portacl.suser_exempt will, - when set to a non-zero value, exempt the - root user from this policy. - - - - security.mac.portacl.rules will - specify the actual mac_portacl policy; see below. - - - - The actual mac_portacl policy, as - specified in the security.mac.portacl.rules - sysctl, is a text string of the form: - rule[,rule,...] with as many rules as - needed. Each rule is of the form: - idtype:id:protocol:port. The - idtype parameter can be - uid or gid and used to - interpret the id parameter as either a - user id or group id, respectively. The - protocol parameter is used to determine if - the rule should apply to TCP or - UDP by setting the parameter to - tcp or udp. The final - port parameter is the port number to allow - the specified user or group to bind to. - - - Since the ruleset is interpreted directly by the kernel - only numeric values can be used for the user ID, group ID, and - port parameters. Names cannot be used for users, groups, or - services. - - - By default, on &unix;-like systems, ports below 1024 - can only be used by/bound to privileged processes, - i.e., those run as root. For - &man.mac.portacl.4; to allow non-privileged processes to bind - to ports below 1024 this standard &unix; restriction has to be - disabled. This can be accomplished by setting the &man.sysctl.8; - variables net.inet.ip.portrange.reservedlow and - net.inet.ip.portrange.reservedhigh - to zero. - - See the examples below or review the &man.mac.portacl.4; - manual page for further information. - - - Examples - - The following examples should illuminate the above - discussion a little better: - - &prompt.root; sysctl security.mac.portacl.port_high=1023 -&prompt.root; sysctl net.inet.ip.portrange.reservedlow=0 net.inet.ip.portrange.reservedhigh=0 - - First we set &man.mac.portacl.4; to cover the standard - privileged ports and disable the normal &unix; bind - restrictions. - - &prompt.root; sysctl security.mac.portacl.suser_exempt=1 - - The root user should not be crippled - by this policy, thus set the - security.mac.portacl.suser_exempt to a - non-zero value. The &man.mac.portacl.4; module - has now been set up to behave the same way &unix;-like systems - behave by default. - - &prompt.root; sysctl security.mac.portacl.rules=uid:80:tcp:80 - - Allow the user with UID 80 (normally - the www user) to bind to port 80. - This can be used to allow the www - user to run a web server without ever having - root privilege. - - &prompt.root; sysctl security.mac.portacl.rules=uid:1001:tcp:110,uid:1001:tcp:995 - - Permit the user with the UID of - 1001 to bind to the TCP ports 110 - (pop3) and 995 (pop3s). - This will permit this user to start a server that accepts - connections on ports 110 and 995. - - - - - The MAC partition Module - - - MAC Process Partition Policy - - Module name: mac_partition.ko - - Kernel configuration line: - options MAC_PARTITION - - Boot option: - mac_partition_load="YES" - - The &man.mac.partition.4; policy will drop processes into - specific partitions based on their - MAC label. Think of it as a special - type of &man.jail.8;, though that is hardly a worthy - comparison. - - This is one module that should be added to the - &man.loader.conf.5; file so that it loads - and enables the policy during the boot process. - - Most configuration for this policy is done using - the &man.setpmac.8; utility which will be explained below. - The following sysctl tunable is - available for this policy: - - - - security.mac.partition.enabled will - enable the enforcement of MAC process - partitions. - - - - When this policy is enabled, users will only be permitted - to see their processes, and any others within their partition, - but will not be permitted to work with - utilities outside the scope of this partition. For instance, a user in the - insecure class above will not be permitted - to access the top command as well as many - other commands that must spawn a process. - - To set or drop utilities into a partition label, use the - setpmac utility: - - &prompt.root; setpmac partition/13 top - - This will add the top command to the - label set on users in the insecure class. - Note that all processes spawned by users - in the insecure class will stay in the - partition/13 label. - - - Examples - - The following command will show you the partition label - and the process list: - - &prompt.root; ps Zax - - This next command will allow the viewing of another - user's process partition label and that user's currently - running processes: - - &prompt.root; ps -ZU trhodes - - - Users can see processes in root's - label unless the &man.mac.seeotheruids.4; policy is - loaded. - - - A really crafty implementation could have all of the - services disabled in /etc/rc.conf and - started by a script that starts them with the proper - labeling set. - - - The following policies support integer settings - in place of the three default labels offered. These options, - including their limitations, are further explained in - the module manual pages. - - - - - - The MAC Multi-Level Security Module - - - MAC Multi-Level Security Policy - - Module name: mac_mls.ko - - Kernel configuration line: - options MAC_MLS - - Boot option: mac_mls_load="YES" - - The &man.mac.mls.4; policy controls access between subjects - and objects in the system by enforcing a strict information - flow policy. - - In MLS environments, a - clearance level is set in each subject or objects - label, along with compartments. Since these clearance or - sensibility levels can reach numbers greater than six thousand; - it would be a daunting task for any system administrator to - thoroughly configure each subject or object. Thankfully, three - instant labels are already included in this - policy. - - These labels are mls/low, - mls/equal and mls/high. - Since these labels are described in depth in the manual page, - they will only get a brief description here: - - - - The mls/low label contains a low - configuration which permits it to be dominated by all other - objects. Anything labeled with mls/low - will have a low clearance level and not be permitted to access - information of a higher level. In addition, this label will - prevent objects of a higher clearance level from writing or - passing information on to them. - - - - The mls/equal label should be - placed on objects considered to be exempt from the - policy. - - - - The mls/high label is the highest level - of clearance possible. Objects assigned this label will - hold dominance over all other objects in the system; however, - they will not permit the leaking of information to objects - of a lower class. - - - - MLS provides for: - - - - A hierarchical security level with a set of non - hierarchical categories; - - - - Fixed rules: no read up, no write down (a subject can - have read access to objects on its own level or below, but - not above. Similarly, a subject can have write access to - objects on its own level or above but not beneath.); - - - - Secrecy (preventing inappropriate disclosure - of data); - - - - Basis for the design of systems that concurrently handle - data at multiple sensitivity levels (without leaking - information between secret and confidential). - - - - The following sysctl tunables are - available for the configuration of special services and - interfaces: - - - - security.mac.mls.enabled is used to - enable/disable the MLS policy. - - - - security.mac.mls.ptys_equal will label - all &man.pty.4; devices as mls/equal during - creation. - - - - security.mac.mls.revocation_enabled is - used to revoke access to objects after their label changes - to a label of a lower grade. - - - - security.mac.mls.max_compartments is - used to set the maximum number of compartment levels with - objects; basically the maximum compartment number allowed - on a system. - - - - To manipulate the MLS labels, the - &man.setfmac.8; command has been provided. To assign a label - to an object, issue the following command: - - &prompt.root; setfmac mls/5 test - - To get the MLS label for the file - test issue the following command: - - &prompt.root; getfmac test - - This is a summary of the MLS - policy's features. Another approach is to create a master policy - file in /etc which - specifies the MLS policy information and to - feed that file into the setfmac command. This - method will be explained after all policies are covered. - - - Planning Mandatory Sensitivity - - With the Multi-Level Security Policy Module, an - administrator plans for controlling the flow of sensitive - information. By default, with its block read up block write - down nature, the system defaults everything to a low state. - Everything is accessible and an administrator - slowly changes this during the configuration stage; augmenting - the confidentiality of the information. - - Beyond the three basic label options above, an administrator - may group users and groups as required to block the information - flow between them. It might be easier to look at the - information in clearance levels familiarized with words, for - instance classifications such as - Confidential, Secret, - and Top Secret. Some administrators might - just create different groups based on project levels. - Regardless of classification method, a well thought out plan - must exist before implementing such a restrictive policy. - - Some example situations for this security policy module - could be an e-commerce web server, a file server holding critical - company information, and financial institution environments. - The most unlikely place would be a personal workstation with - only two or three users. - - - - - The MAC Biba Module - - - MAC Biba Integrity Policy - - Module name: mac_biba.ko - - Kernel configuration line: options MAC_BIBA - - Boot option: mac_biba_load="YES" - - The &man.mac.biba.4; module loads the MAC - Biba policy. This policy works much like that of the - MLS policy with the exception that the rules - for information flow - are slightly reversed. This is said to prevent the downward - flow of sensitive information whereas the MLS - policy prevents the upward flow of sensitive information; thus, - much of this section can apply to both policies. - - In Biba environments, an integrity label is - set on each subject or object. These labels are made up of - hierarchal grades, and non-hierarchal components. As an object's - or subject's grade ascends, so does its integrity. - - Supported labels are biba/low, - biba/equal, and biba/high; - as explained below: - - - - The biba/low label is considered the - lowest integrity an object or subject may have. Setting - this on objects or subjects will block their write access - to objects or subjects marked high. They still have read - access though. - - - - The biba/equal label should only be - placed on objects considered to be exempt from the - policy. - - - - The biba/high label will permit - writing to objects set at a lower label, but not - permit reading that object. It is recommended that this - label be placed on objects that affect the integrity of - the entire system. - - - - Biba provides for: - - - - Hierarchical integrity level with a set of non - hierarchical integrity categories; - - - - Fixed rules: no write up, no read down (opposite of - MLS). A subject can have write access - to objects on its own level or below, but not above. Similarly, a - subject can have read access to objects on its own level - or above, but not below; - - - - Integrity (preventing inappropriate modification of - data); - - - - Integrity levels (instead of MLS sensitivity - levels). - - - - The following sysctl tunables can - be used to manipulate the Biba policy. - - - - security.mac.biba.enabled may be used - to enable/disable enforcement of the Biba policy on the - target machine. - - - - security.mac.biba.ptys_equal may be - used to disable the Biba policy on &man.pty.4; - devices. - - - - security.mac.biba.revocation_enabled - will force the revocation of access to objects if the label - is changed to dominate the subject. - - - - To access the Biba policy setting on system objects, use - the setfmac and getfmac - commands: - - &prompt.root; setfmac biba/low test -&prompt.root; getfmac test -test: biba/low - - - Planning Mandatory Integrity - - Integrity, different from sensitivity, guarantees that the - information will never be manipulated by untrusted parties. - This includes information passed between subjects, objects, - and both. It ensures that users will only be able to modify - and in some cases even access information they explicitly need - to. - - The &man.mac.biba.4; security policy module permits an - administrator to address which files and programs a user or - users may see and invoke while assuring that the programs and - files are free from threats and trusted by the system for that - user, or group of users. - - During the initial planning phase, an administrator must be - prepared to partition users into grades, levels, and areas. - Users will be blocked access not only to data but programs - and utilities both before and after they start. The system will - default to a high label once this policy module is enabled, and - it is up to the administrator to configure the different grades - and levels for users. Instead of using clearance levels as - described above, a good planning method could include topics. - For instance, only allow developers modification access to the source code - repository, source code compiler, and other development - utilities. While other users would be grouped into other - categories such as testers, designers, or just ordinary - users and would only be permitted read access. - - With its natural security control, a lower integrity subject - is unable to write to a higher integrity subject; a higher - integrity subject cannot observe or read a lower integrity - object. Setting a label at the lowest possible grade could make - it inaccessible to subjects. Some prospective environments for - this security policy module would include a constrained web - server, development and test machine, and source code - repository. A less useful implementation would be a personal - workstation, a machine used as a router, or a network - firewall. - - - - - The MAC LOMAC Module - - - MAC LOMAC - - Module name: mac_lomac.ko - - Kernel configuration line: options MAC_LOMAC - Boot option: mac_lomac_load="YES" - - Unlike the MAC Biba policy, the - &man.mac.lomac.4; policy permits access to lower integrity - objects only after decreasing the integrity level to not disrupt - any integrity rules. - - The MAC version of the Low-watermark - integrity policy, not to be confused with the older &man.lomac.4; - implementation, works almost identically to Biba, but with the - exception of using floating labels to support subject - demotion via an auxiliary grade compartment. This secondary - compartment takes the form of [auxgrade]. - When assigning a lomac policy with an auxiliary grade, it - should look a little bit like: lomac/10[2] - where the number two (2) is the auxiliary grade. - - The MAC LOMAC policy relies on the - ubiquitous labeling of all system objects with integrity labels, - permitting subjects to read from low integrity objects and then - downgrading the label on the subject to prevent future writes to - high integrity objects. This is the - [auxgrade] option discussed above, thus the - policy may provide for greater compatibility and require less - initial configuration than Biba. - - - Examples - - Like the Biba and MLS policies; - the setfmac and setpmac - utilities may be used to place labels on system objects: - - &prompt.root; setfmac /usr/home/trhodes lomac/high[low] -&prompt.root; getfmac /usr/home/trhodes lomac/high[low] - - Notice the auxiliary grade here is low, - this is a feature provided only by the MAC - LOMAC policy. - - - - - Nagios in a MAC Jail - - - Nagios in a MAC Jail - - - The following demonstration will implement a secure - environment using various MAC modules - with properly configured policies. This is only a test and - should not be considered the complete answer to everyone's - security woes. Just implementing a policy and ignoring it - never works and could be disastrous in a production - environment. - - Before beginning this process, the - multilabel option must be set on each file - system as stated at the beginning of this chapter. Not doing - so will result in errors. While at it, ensure that the - net-mngt/nagios-plugins, - net-mngt/nagios, and - www/apache22 ports are all - installed, configured, and working correctly. - - - Create an insecure User Class - - Begin the procedure by adding the following user class - to the /etc/login.conf file: - - insecure:\ -:copyright=/etc/COPYRIGHT:\ -:welcome=/etc/motd:\ -:setenv=MAIL=/var/mail/$,BLOCKSIZE=K:\ -:path=~/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin -:manpath=/usr/share/man /usr/local/man:\ -:nologin=/usr/sbin/nologin:\ -:cputime=1h30m:\ -:datasize=8M:\ -:vmemoryuse=100M:\ -:stacksize=2M:\ -:memorylocked=4M:\ -:memoryuse=8M:\ -:filesize=8M:\ -:coredumpsize=8M:\ -:openfiles=24:\ -:maxproc=32:\ -:priority=0:\ -:requirehome:\ -:passwordtime=91d:\ -:umask=022:\ -:ignoretime@:\ -:label=biba/10(10-10): - - And adding the following line to the default user - class: - - :label=biba/high: - - Once this is completed, the following command must be - issued to rebuild the database: - - &prompt.root; cap_mkdb /etc/login.conf - - - - Boot Configuration - - Do not reboot yet, just add the following lines to - /boot/loader.conf so the required - modules will load during system initialization: - - mac_biba_load="YES" -mac_seeotheruids_load="YES" - - - - Configure Users - - Set the root user to the default - class using: - - &prompt.root; pw usermod root -L default - - All user accounts that are not root - or system users will now require a login class. The login - class is required otherwise users will be refused access - to common commands such as &man.vi.1;. - The following sh script should do the - trick: - - &prompt.root; for x in `awk -F: '($3 >= 1001) && ($3 != 65534) { print $1 }' \ - /etc/passwd`; do pw usermod $x -L default; done; - - Drop the nagios and - www users into the insecure class: - - &prompt.root; pw usermod nagios -L insecure - &prompt.root; pw usermod www -L insecure - - - - Create the Contexts File - - A contexts file should now be created; the following example - file should be placed in - /etc/policy.contexts. - - # This is the default BIBA policy for this system. - -# System: -/var/run biba/equal -/var/run/* biba/equal - -/dev biba/equal -/dev/* biba/equal - -/var biba/equal -/var/spool biba/equal -/var/spool/* biba/equal - -/var/log biba/equal -/var/log/* biba/equal - -/tmp biba/equal -/tmp/* biba/equal -/var/tmp biba/equal -/var/tmp/* biba/equal - -/var/spool/mqueue biba/equal -/var/spool/clientmqueue biba/equal - -# For Nagios: -/usr/local/etc/nagios -/usr/local/etc/nagios/* biba/10 - -/var/spool/nagios biba/10 -/var/spool/nagios/* biba/10 - -# For apache -/usr/local/etc/apache biba/10 -/usr/local/etc/apache/* biba/10 - - This policy will enforce security by setting restrictions - on the flow of information. In this specific configuration, - users, root and others, should never be - allowed to access Nagios. - Configuration files and processes that are a part of - Nagios will be completely self - contained or jailed. - - This file may now be read into our system by issuing the - following command: - - &prompt.root; setfsmac -ef /etc/policy.contexts / -&prompt.root; setfsmac -ef /etc/policy.contexts / - - - The above file system layout may be different depending - on environment; however, it must be run on every single file - system. - - - The /etc/mac.conf file requires - the following modifications in the main section: - - default_labels file ?biba -default_labels ifnet ?biba -default_labels process ?biba -default_labels socket ?biba - - - - Enable Networking - - Add the following line to - /boot/loader.conf: - - security.mac.biba.trust_all_interfaces=1 - - And the following to the network card configuration stored - in rc.conf. If the primary Internet - configuration is done via DHCP, this may - need to be configured manually after every system boot: - - maclabel biba/equal - - - - Testing the Configuration - - - MAC Configuration Testing - - - Ensure that the web server and - Nagios will not be started - on system initialization, and reboot. Ensure the - root user cannot access any of the files - in the Nagios configuration - directory. If root can issue an &man.ls.1; - command on /var/spool/nagios, then something - is wrong. Otherwise a permission denied error - should be returned. - - If all seems well, Nagios, - Apache, and - Sendmail can now be started in a way - fitting of the security policy. The following commands will - make this happen: - - &prompt.root; cd /etc/mail && make stop && \ -setpmac biba/equal make start && setpmac biba/10\(10-10\) apachectl start && \ -setpmac biba/10\(10-10\) /usr/local/etc/rc.d/nagios.sh forcestart - - Double check to ensure that everything is working - properly. If not, check the log files or error messages. Use - the &man.sysctl.8; utility to disable the &man.mac.biba.4; - security policy module enforcement and try starting everything - again, like normal. - - - The root user can change the security - enforcement and edit the configuration files without fear. - The following command will permit the degradation of the - security policy to a lower grade for a newly spawned - shell: - - &prompt.root; setpmac biba/10 csh - - To block this from happening, force the user into a range - via &man.login.conf.5;. If &man.setpmac.8; attempts to run - a command outside of the compartment's range, an error will - be returned and the command will not be executed. In this - case, setting root to - biba/high(high-high). - - - - - - User Lock Down - - This example considers a relatively small, fewer than fifty - users, storage system. Users would have login capabilities, and - be permitted to not only store data but access resources as - well. - - For this scenario, the &man.mac.bsdextended.4; mixed with - &man.mac.seeotheruids.4; could co-exist and block access not - only to system objects, but to hide user processes as - well. - - Begin by adding the following line to - /boot/loader.conf: - - mac_seeotheruids_load="YES" - - The &man.mac.bsdextended.4; security policy module may be - activated through the use of the following rc.conf - variable: - - ugidfw_enable="YES" - - Default rules stored in - /etc/rc.bsdextended will be loaded at system - initialization; however, the default entries may need - modification. Since this machine is expected only to service - users, everything may be left commented out except the last - two. These will force the loading of user owned system objects - by default. - - Add the required users to this machine and reboot. For - testing purposes, try logging in as a different user across two - consoles. Run the ps aux command to see if - processes of other users are visible. Try to run &man.ls.1; on - another users home directory, it should fail. - - Do not try to test with the root user - unless the specific sysctls have been modified - to block super user access. - - - When a new user is added, their &man.mac.bsdextended.4; - rule will not be in the ruleset list. To update the ruleset - quickly, simply unload the security policy module and reload - it again using the &man.kldunload.8; and &man.kldload.8; - utilities. - - - - - Troubleshooting the MAC Framework - - - MAC Troubleshooting - - - During the development stage, a few users reported problems - with normal configuration. Some of these problems - are listed below: - - - The <option>multilabel</option> option cannot be enabled on - <filename>/</filename> - - The flag does not stay - enabled on my root (/) partition! - - - It seems that one out of every fifty users has this - problem, indeed, we had this problem during our initial - configuration. Further observation of this so called - bug has lead me to believe that it is a - result of either incorrect documentation or misinterpretation - of the documentation. Regardless of why it happened, the - following steps may be taken to resolve it: - - - - Edit /etc/fstab and set the root - partition at for read-only. - - - - Reboot into single user mode. - - - - Run tunefs - on /. - - - - Reboot the system into normal mode. - - - - Run mount - / and change the - back to in /etc/fstab - and reboot the system again. - - - - Double-check the output from the - mount to ensure that - has been properly set on the - root file system. - - - - - - X11 Server Will Not Start After <acronym>MAC</acronym> - - After establishing a secure environment with - MAC, I am no longer able to start - X! - - This could be caused by the MAC - partition policy or by a mislabeling in - one of the MAC labeling policies. To - debug, try the following: - - - - Check the error message; if the user is in the - insecure class, the - partition policy may be the culprit. - Try setting the user's class back to the - default class and rebuild the database - with the cap_mkdb command. If this - does not alleviate the problem, go to step two. - - - - Double-check the label policies. Ensure that the - policies are set correctly for the user in question, the - X11 application, and - the /dev - entries. - - - - If neither of these resolve the problem, send the - error message and a description of your environment to - the TrustedBSD discussion lists located at the - TrustedBSD - website or to the &a.questions; - mailing list. - - - - - - Error: &man..secure.path.3; cannot stat <filename>.login_conf</filename> - - When I attempt to switch from the root user - to another user in the system, the error message - _secure_path: unable to state .login_conf appears. - - This message is usually shown when the user has a higher - label setting then that of the user whom they are attempting to - become. For instance a user on the system, - joe, has a default label of - . The root user, - who has a label of , cannot view - joe's home directory. This will happen - regardless if root has used the - su command to become joe, - or not. In this scenario, the Biba integrity model will not - permit root to view objects set at a lower - integrity level. - - - - The <username>root</username> username is broken! - - In normal or even single user mode, the - root is not recognized. The - whoami command returns 0 (zero) and - su returns who are you?. - What could be going on? - - This can happen if a labeling policy has been disabled, - either by a &man.sysctl.8; or the policy module was unloaded. - If the policy is being disabled or has been temporarily - disabled, then the login capabilities database needs to be - reconfigured with the option being - removed. Double check the login.conf - file to ensure that all options have - been removed and rebuild the database with the - cap_mkdb command. - - This may also happen if a policy restricts access to the - master.passwd file or database. Usually - caused by an administrator altering the file under a label - which conflicts with the general policy being used by the - system. In these cases, the user information would be read - by the system and access would be blocked as the file has - inherited the new label. Disable the policy via a - &man.sysctl.8; and everything should return to normal. - - - diff --git a/en_US.ISO8859-1/books/handbook/mac/chapter.xml b/en_US.ISO8859-1/books/handbook/mac/chapter.xml new file mode 100644 index 0000000000..f94e9d5aa1 --- /dev/null +++ b/en_US.ISO8859-1/books/handbook/mac/chapter.xml @@ -0,0 +1,2075 @@ + + + + + + + + Tom + Rhodes + Written by + + + + + Mandatory Access Control + + + Synopsis + + MAC + + Mandatory Access Control + 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. 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. + + After reading this chapter, you will know: + + + + What MAC security policy modules are currently + 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. + + + + How to efficiently configure a system to use + the MAC framework. + + + + How to configure the different security policy modules included with the + MAC framework. + + + + How to implement a more secure environment using the + MAC framework and the examples + shown. + + + + How to test the MAC configuration + to ensure the framework has been properly implemented. + + + + Before reading this chapter, you should: + + + + Understand &unix; and &os; basics + (). + + + + 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. + + + + What Will Not Be Covered + + 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 the &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 pages. + + + + + 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. + + + + 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. + + + + 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 + is complete. Currently, the &os; MAC + framework does not have a policy for this, but the definition + is included for completeness. + + + + 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 + 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. + + + + 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;. + + + + 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. + + + + 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. + + + + 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. + + + + 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 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. + + + + 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 thread + acting in a process on behalf of a user. + + + + + + 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, 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. + + 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 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. + + + + + Understanding MAC Labels + + 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. 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. + + 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. + + 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 + policy modules. + + 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 where multiple labels may be set on objects + or subjects in the file system. For those cases, the + option may be passed 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 + 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 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 + by policies such as Biba and MLS. + + + Label 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 + 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: + + &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 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. The system administrator + may use the following commands to overcome this: + + &prompt.root; setfmac biba/high test +Permission denied +&prompt.root; setpmac biba/low setfmac biba/high test +&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. + + + Common Label Types + + 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: + + + + 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. + + + + The equal label should only be + placed on objects considered to be exempt from the + policy. + + + + The high label grants an object or + subject the highest possible setting. + + + + 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 configurations. + + + Advanced Label Configuration + + Numeric grade labels are used for + comparison:compartment+compartment; thus + the following: + + biba/10:2+3+6(5:2+3-20:2+3+4+5+6) + + 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. + + The grade and compartments in a subject and object pair + are used to construct a relationship referred to 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. + + + + + 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. + + An example entry containing every policy module setting is displayed + below: + + default:\ + :copyright=/etc/COPYRIGHT:\ + :welcome=/etc/motd:\ + :setenv=MAIL=/var/mail/$,BLOCKSIZE=K:\ + :path=~/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:\ + :manpath=/usr/share/man /usr/local/man:\ + :nologin=/usr/sbin/nologin:\ + :cputime=1h30m:\ + :datasize=8M:\ + :vmemoryuse=100M:\ + :stacksize=2M:\ + :memorylocked=4M:\ + :memoryuse=8M:\ + :filesize=8M:\ + :coredumpsize=8M:\ + :openfiles=24:\ + :maxproc=32:\ + :priority=0:\ + :requirehome:\ + :passwordtime=91d:\ + :umask=022:\ + :ignoretime@:\ + :label=partition/13,mls/5,biba/10(5-15),lomac/10[2]: + + The label option is used 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. + + + 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 + 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. + + + + 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. + + The may be passed to + ifconfig when setting the + MAC label on network interfaces. For + example: + + &prompt.root; ifconfig bge0 maclabel biba/equal + + 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 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. + + + + + 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: + + + + &os; web-server using the MAC + framework and a mix of the various policies. + + + + 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. + + + + 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. + + + + 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 + nodes. + + The following command will set + on the file systems to have multiple labels. This may only be + done in single user mode: + + &prompt.root; tunefs -l enable / + + This is not a requirement for the swap file + system. + + + Some users have experienced problems with setting the + flag on the root partition. + If this is the case, please review the + of this chapter. + + + + + + Planning the Security Configuration + + Whenever a new technology is implemented, a planning phase is + always a good idea. During the planning stages, an administrator + should in general look at the big picture, trying + to keep in view at least the following: + + + + The implementation requirements; + + + + The implementation goals; + + + + For MAC installations, these include: + + + + How to classify information and resources available on + the target systems. + + + + What sorts of information or resources to restrict + access to along with the type of restrictions that should be + applied. + + + + Which MAC module or modules will be + required to achieve this goal. + + + + It is always possible to reconfigure and change the + system resources and security settings, it is quite often very inconvenient to + search through the system and fix existing files and user + accounts. Planning helps to ensure a trouble-free and efficient + trusted system implementation. A trial run of the trusted system, + including the configuration, is often vital and definitely + beneficial before a MAC + implementation is used on production systems. The idea of just + letting loose on a system + with MAC is like setting up for failure. + + Different environments may have explicit needs and + requirements. Establishing an in depth and complete security + profile will decrease the need of changes once the system + goes live. As such, the future sections will cover the + different modules available to administrators; describe their + use and configuration; and in some cases provide insight on + what situations they would be most suitable for. For instance, + a web server might roll out the &man.mac.biba.4; and + &man.mac.bsdextended.4; policies. In other cases, a machine + with very few local users, the &man.mac.partition.4; might + be a good choice. + + + + Module Configuration + + Every module included with the MAC + framework may be either compiled into the kernel as noted above + or loaded as a run-time kernel module. + The recommended method is to add the module name to the + /boot/loader.conf file so that it will load + during the initial boot operation. + + The following sections will discuss the various + MAC modules and cover their features. + Implementing them into a specific environment will also + be a consideration of this chapter. Some modules support + the use of labeling, which is controlling access by enforcing + a label such as this is allowed and this is not. + A label configuration file may control how files may be accessed, + network communication can be exchanged, and more. The previous + section showed how the flag could + be set on file systems to enable per-file or per-partition + access control. + + A single label configuration would enforce only one label + across the system, that is why the tunefs + option is called . + + + + The MAC seeotheruids Module + + + MAC See Other UIDs Policy + + Module name: mac_seeotheruids.ko + + Kernel configuration line: + options MAC_SEEOTHERUIDS + + Boot option: + mac_seeotheruids_load="YES" + + The &man.mac.seeotheruids.4; module mimics and extends + the security.bsd.see_other_uids and + security.bsd.see_other_gids + sysctl tunables. This option does + not require any labels to be set before configuration and + can operate transparently with the other modules. + + After loading the module, the following + sysctl tunables may be used to control + the features: + + + + security.mac.seeotheruids.enabled + will enable the module's features and use the default + settings. These default settings will deny users the + ability to view processes and sockets owned by other + users. + + + + + security.mac.seeotheruids.specificgid_enabled + will allow a certain group to be exempt from this policy. + To exempt specific groups from this policy, use the + security.mac.seeotheruids.specificgid=XXX + sysctl tunable. In the above example, + the XXX should be replaced with the + numeric group ID to be exempted. + + + + + security.mac.seeotheruids.primarygroup_enabled + is used to exempt specific primary groups from this policy. + When using this tunable, the + security.mac.seeotheruids.specificgid_enabled + may not be set. + + + + + + The MAC bsdextended Module + + + MAC + File System Firewall Policy + + Module name: mac_bsdextended.ko + + Kernel configuration line: + options MAC_BSDEXTENDED + + Boot option: + mac_bsdextended_load="YES" + + The &man.mac.bsdextended.4; module enforces the file system + firewall. This module's policy provides an extension to the + standard file system permissions model, permitting an + administrator to create a firewall-like ruleset to protect files, + utilities, and directories in the file system hierarchy. When + access to a file system object is attempted, the list of rules + is iterated until either a matching rule is located or the end + is reached. This behavior may be changed by the use of a + &man.sysctl.8; parameter, + security.mac.bsdextended.firstmatch_enabled. Similar to + other firewall modules in &os;, a file containing access control + rules can be created and read by the system at boot time using + an &man.rc.conf.5; variable. + + The rule list may be entered using a utility, &man.ugidfw.8;, + that has a syntax similar to that of &man.ipfw.8;. More tools + can be written by using the functions in the + &man.libugidfw.3; library. + + Extreme caution should be taken when working with this + module; incorrect use could block access to certain parts of + the file system. + + + Examples + + After the &man.mac.bsdextended.4; module has + been loaded, the following command may be used to list the + current rule configuration: + + &prompt.root; ugidfw list +0 slots, 0 rules + + As expected, there are no rules defined. This means that + everything is still completely accessible. To create a rule + which will block all access by users but leave + root unaffected, simply run the + following command: + + &prompt.root; ugidfw add subject not uid root new object not uid root mode n + + This is a very bad idea as it will block all users from + issuing even the most simple commands, such as + ls. A more patriotic list of rules + might be: + + &prompt.root; ugidfw set 2 subject uid user1 object uid user2 mode n +&prompt.root; ugidfw set 3 subject uid user1 object gid user2 mode n + + This will block any and all access, including directory + listings, to user2's home + directory from the username user1. + + In place of user1, the + could + be passed. This will enforce the same access restrictions + above for all users in place of just one user. + + + The root user will be unaffected + by these changes. + + + This should provide a general idea of how the + &man.mac.bsdextended.4; module may be used to help fortify + a file system. For more information, see the + &man.mac.bsdextended.4; and the &man.ugidfw.8; manual + pages. + + + + + The MAC ifoff Module + + + MAC Interface Silencing Policy + + Module name: mac_ifoff.ko + + Kernel configuration line: + options MAC_IFOFF + + Boot option: mac_ifoff_load="YES" + + The &man.mac.ifoff.4; module exists solely to disable network + interfaces on the fly and keep network interfaces from being + brought up during the initial system boot. It does not require + any labels to be set up on the system, nor does it have a + dependency on other MAC modules. + + Most of the control is done through the + sysctl tunables listed below. + + + + security.mac.ifoff.lo_enabled will + enable/disable all traffic on the loopback (&man.lo.4;) + interface. + + + + security.mac.ifoff.bpfrecv_enabled will + enable/disable all traffic on the Berkeley Packet Filter + interface (&man.bpf.4;) + + + + security.mac.ifoff.other_enabled will + enable/disable traffic on all other interfaces. + + + + One of the most common uses of &man.mac.ifoff.4; is network + monitoring in an environment where network traffic should not + be permitted during the boot sequence. Another suggested use + would be to write a script which uses + security/aide to automatically + block network traffic if it finds new or altered files in + protected directories. + + + + The MAC portacl Module + + + MAC Port Access Control List Policy + + Module name: mac_portacl.ko + + Kernel configuration line: + MAC_PORTACL + + Boot option: mac_portacl_load="YES" + + The &man.mac.portacl.4; module is used to limit binding to + local TCP and UDP ports + using a variety of sysctl variables. In + essence &man.mac.portacl.4; makes it possible to allow + non-root users to bind to specified + privileged ports, i.e., ports below 1024. + + Once loaded, this module will enable the + MAC policy on all sockets. The following + tunables are available: + + + + security.mac.portacl.enabled will + enable/disable the policy completely. + + + + security.mac.portacl.port_high will set + the highest port number that &man.mac.portacl.4; + will enable protection for. + + + + security.mac.portacl.suser_exempt will, + when set to a non-zero value, exempt the + root user from this policy. + + + + security.mac.portacl.rules will + specify the actual mac_portacl policy; see below. + + + + The actual mac_portacl policy, as + specified in the security.mac.portacl.rules + sysctl, is a text string of the form: + rule[,rule,...] with as many rules as + needed. Each rule is of the form: + idtype:id:protocol:port. The + idtype parameter can be + uid or gid and used to + interpret the id parameter as either a + user id or group id, respectively. The + protocol parameter is used to determine if + the rule should apply to TCP or + UDP by setting the parameter to + tcp or udp. The final + port parameter is the port number to allow + the specified user or group to bind to. + + + Since the ruleset is interpreted directly by the kernel + only numeric values can be used for the user ID, group ID, and + port parameters. Names cannot be used for users, groups, or + services. + + + By default, on &unix;-like systems, ports below 1024 + can only be used by/bound to privileged processes, + i.e., those run as root. For + &man.mac.portacl.4; to allow non-privileged processes to bind + to ports below 1024 this standard &unix; restriction has to be + disabled. This can be accomplished by setting the &man.sysctl.8; + variables net.inet.ip.portrange.reservedlow and + net.inet.ip.portrange.reservedhigh + to zero. + + See the examples below or review the &man.mac.portacl.4; + manual page for further information. + + + Examples + + The following examples should illuminate the above + discussion a little better: + + &prompt.root; sysctl security.mac.portacl.port_high=1023 +&prompt.root; sysctl net.inet.ip.portrange.reservedlow=0 net.inet.ip.portrange.reservedhigh=0 + + First we set &man.mac.portacl.4; to cover the standard + privileged ports and disable the normal &unix; bind + restrictions. + + &prompt.root; sysctl security.mac.portacl.suser_exempt=1 + + The root user should not be crippled + by this policy, thus set the + security.mac.portacl.suser_exempt to a + non-zero value. The &man.mac.portacl.4; module + has now been set up to behave the same way &unix;-like systems + behave by default. + + &prompt.root; sysctl security.mac.portacl.rules=uid:80:tcp:80 + + Allow the user with UID 80 (normally + the www user) to bind to port 80. + This can be used to allow the www + user to run a web server without ever having + root privilege. + + &prompt.root; sysctl security.mac.portacl.rules=uid:1001:tcp:110,uid:1001:tcp:995 + + Permit the user with the UID of + 1001 to bind to the TCP ports 110 + (pop3) and 995 (pop3s). + This will permit this user to start a server that accepts + connections on ports 110 and 995. + + + + + The MAC partition Module + + + MAC Process Partition Policy + + Module name: mac_partition.ko + + Kernel configuration line: + options MAC_PARTITION + + Boot option: + mac_partition_load="YES" + + The &man.mac.partition.4; policy will drop processes into + specific partitions based on their + MAC label. Think of it as a special + type of &man.jail.8;, though that is hardly a worthy + comparison. + + This is one module that should be added to the + &man.loader.conf.5; file so that it loads + and enables the policy during the boot process. + + Most configuration for this policy is done using + the &man.setpmac.8; utility which will be explained below. + The following sysctl tunable is + available for this policy: + + + + security.mac.partition.enabled will + enable the enforcement of MAC process + partitions. + + + + When this policy is enabled, users will only be permitted + to see their processes, and any others within their partition, + but will not be permitted to work with + utilities outside the scope of this partition. For instance, a user in the + insecure class above will not be permitted + to access the top command as well as many + other commands that must spawn a process. + + To set or drop utilities into a partition label, use the + setpmac utility: + + &prompt.root; setpmac partition/13 top + + This will add the top command to the + label set on users in the insecure class. + Note that all processes spawned by users + in the insecure class will stay in the + partition/13 label. + + + Examples + + The following command will show you the partition label + and the process list: + + &prompt.root; ps Zax + + This next command will allow the viewing of another + user's process partition label and that user's currently + running processes: + + &prompt.root; ps -ZU trhodes + + + Users can see processes in root's + label unless the &man.mac.seeotheruids.4; policy is + loaded. + + + A really crafty implementation could have all of the + services disabled in /etc/rc.conf and + started by a script that starts them with the proper + labeling set. + + + The following policies support integer settings + in place of the three default labels offered. These options, + including their limitations, are further explained in + the module manual pages. + + + + + + The MAC Multi-Level Security Module + + + MAC Multi-Level Security Policy + + Module name: mac_mls.ko + + Kernel configuration line: + options MAC_MLS + + Boot option: mac_mls_load="YES" + + The &man.mac.mls.4; policy controls access between subjects + and objects in the system by enforcing a strict information + flow policy. + + In MLS environments, a + clearance level is set in each subject or objects + label, along with compartments. Since these clearance or + sensibility levels can reach numbers greater than six thousand; + it would be a daunting task for any system administrator to + thoroughly configure each subject or object. Thankfully, three + instant labels are already included in this + policy. + + These labels are mls/low, + mls/equal and mls/high. + Since these labels are described in depth in the manual page, + they will only get a brief description here: + + + + The mls/low label contains a low + configuration which permits it to be dominated by all other + objects. Anything labeled with mls/low + will have a low clearance level and not be permitted to access + information of a higher level. In addition, this label will + prevent objects of a higher clearance level from writing or + passing information on to them. + + + + The mls/equal label should be + placed on objects considered to be exempt from the + policy. + + + + The mls/high label is the highest level + of clearance possible. Objects assigned this label will + hold dominance over all other objects in the system; however, + they will not permit the leaking of information to objects + of a lower class. + + + + MLS provides for: + + + + A hierarchical security level with a set of non + hierarchical categories; + + + + Fixed rules: no read up, no write down (a subject can + have read access to objects on its own level or below, but + not above. Similarly, a subject can have write access to + objects on its own level or above but not beneath.); + + + + Secrecy (preventing inappropriate disclosure + of data); + + + + Basis for the design of systems that concurrently handle + data at multiple sensitivity levels (without leaking + information between secret and confidential). + + + + The following sysctl tunables are + available for the configuration of special services and + interfaces: + + + + security.mac.mls.enabled is used to + enable/disable the MLS policy. + + + + security.mac.mls.ptys_equal will label + all &man.pty.4; devices as mls/equal during + creation. + + + + security.mac.mls.revocation_enabled is + used to revoke access to objects after their label changes + to a label of a lower grade. + + + + security.mac.mls.max_compartments is + used to set the maximum number of compartment levels with + objects; basically the maximum compartment number allowed + on a system. + + + + To manipulate the MLS labels, the + &man.setfmac.8; command has been provided. To assign a label + to an object, issue the following command: + + &prompt.root; setfmac mls/5 test + + To get the MLS label for the file + test issue the following command: + + &prompt.root; getfmac test + + This is a summary of the MLS + policy's features. Another approach is to create a master policy + file in /etc which + specifies the MLS policy information and to + feed that file into the setfmac command. This + method will be explained after all policies are covered. + + + Planning Mandatory Sensitivity + + With the Multi-Level Security Policy Module, an + administrator plans for controlling the flow of sensitive + information. By default, with its block read up block write + down nature, the system defaults everything to a low state. + Everything is accessible and an administrator + slowly changes this during the configuration stage; augmenting + the confidentiality of the information. + + Beyond the three basic label options above, an administrator + may group users and groups as required to block the information + flow between them. It might be easier to look at the + information in clearance levels familiarized with words, for + instance classifications such as + Confidential, Secret, + and Top Secret. Some administrators might + just create different groups based on project levels. + Regardless of classification method, a well thought out plan + must exist before implementing such a restrictive policy. + + Some example situations for this security policy module + could be an e-commerce web server, a file server holding critical + company information, and financial institution environments. + The most unlikely place would be a personal workstation with + only two or three users. + + + + + The MAC Biba Module + + + MAC Biba Integrity Policy + + Module name: mac_biba.ko + + Kernel configuration line: options MAC_BIBA + + Boot option: mac_biba_load="YES" + + The &man.mac.biba.4; module loads the MAC + Biba policy. This policy works much like that of the + MLS policy with the exception that the rules + for information flow + are slightly reversed. This is said to prevent the downward + flow of sensitive information whereas the MLS + policy prevents the upward flow of sensitive information; thus, + much of this section can apply to both policies. + + In Biba environments, an integrity label is + set on each subject or object. These labels are made up of + hierarchal grades, and non-hierarchal components. As an object's + or subject's grade ascends, so does its integrity. + + Supported labels are biba/low, + biba/equal, and biba/high; + as explained below: + + + + The biba/low label is considered the + lowest integrity an object or subject may have. Setting + this on objects or subjects will block their write access + to objects or subjects marked high. They still have read + access though. + + + + The biba/equal label should only be + placed on objects considered to be exempt from the + policy. + + + + The biba/high label will permit + writing to objects set at a lower label, but not + permit reading that object. It is recommended that this + label be placed on objects that affect the integrity of + the entire system. + + + + Biba provides for: + + + + Hierarchical integrity level with a set of non + hierarchical integrity categories; + + + + Fixed rules: no write up, no read down (opposite of + MLS). A subject can have write access + to objects on its own level or below, but not above. Similarly, a + subject can have read access to objects on its own level + or above, but not below; + + + + Integrity (preventing inappropriate modification of + data); + + + + Integrity levels (instead of MLS sensitivity + levels). + + + + The following sysctl tunables can + be used to manipulate the Biba policy. + + + + security.mac.biba.enabled may be used + to enable/disable enforcement of the Biba policy on the + target machine. + + + + security.mac.biba.ptys_equal may be + used to disable the Biba policy on &man.pty.4; + devices. + + + + security.mac.biba.revocation_enabled + will force the revocation of access to objects if the label + is changed to dominate the subject. + + + + To access the Biba policy setting on system objects, use + the setfmac and getfmac + commands: + + &prompt.root; setfmac biba/low test +&prompt.root; getfmac test +test: biba/low + + + Planning Mandatory Integrity + + Integrity, different from sensitivity, guarantees that the + information will never be manipulated by untrusted parties. + This includes information passed between subjects, objects, + and both. It ensures that users will only be able to modify + and in some cases even access information they explicitly need + to. + + The &man.mac.biba.4; security policy module permits an + administrator to address which files and programs a user or + users may see and invoke while assuring that the programs and + files are free from threats and trusted by the system for that + user, or group of users. + + During the initial planning phase, an administrator must be + prepared to partition users into grades, levels, and areas. + Users will be blocked access not only to data but programs + and utilities both before and after they start. The system will + default to a high label once this policy module is enabled, and + it is up to the administrator to configure the different grades + and levels for users. Instead of using clearance levels as + described above, a good planning method could include topics. + For instance, only allow developers modification access to the source code + repository, source code compiler, and other development + utilities. While other users would be grouped into other + categories such as testers, designers, or just ordinary + users and would only be permitted read access. + + With its natural security control, a lower integrity subject + is unable to write to a higher integrity subject; a higher + integrity subject cannot observe or read a lower integrity + object. Setting a label at the lowest possible grade could make + it inaccessible to subjects. Some prospective environments for + this security policy module would include a constrained web + server, development and test machine, and source code + repository. A less useful implementation would be a personal + workstation, a machine used as a router, or a network + firewall. + + + + + The MAC LOMAC Module + + + MAC LOMAC + + Module name: mac_lomac.ko + + Kernel configuration line: options MAC_LOMAC + Boot option: mac_lomac_load="YES" + + Unlike the MAC Biba policy, the + &man.mac.lomac.4; policy permits access to lower integrity + objects only after decreasing the integrity level to not disrupt + any integrity rules. + + The MAC version of the Low-watermark + integrity policy, not to be confused with the older &man.lomac.4; + implementation, works almost identically to Biba, but with the + exception of using floating labels to support subject + demotion via an auxiliary grade compartment. This secondary + compartment takes the form of [auxgrade]. + When assigning a lomac policy with an auxiliary grade, it + should look a little bit like: lomac/10[2] + where the number two (2) is the auxiliary grade. + + The MAC LOMAC policy relies on the + ubiquitous labeling of all system objects with integrity labels, + permitting subjects to read from low integrity objects and then + downgrading the label on the subject to prevent future writes to + high integrity objects. This is the + [auxgrade] option discussed above, thus the + policy may provide for greater compatibility and require less + initial configuration than Biba. + + + Examples + + Like the Biba and MLS policies; + the setfmac and setpmac + utilities may be used to place labels on system objects: + + &prompt.root; setfmac /usr/home/trhodes lomac/high[low] +&prompt.root; getfmac /usr/home/trhodes lomac/high[low] + + Notice the auxiliary grade here is low, + this is a feature provided only by the MAC + LOMAC policy. + + + + + Nagios in a MAC Jail + + + Nagios in a MAC Jail + + + The following demonstration will implement a secure + environment using various MAC modules + with properly configured policies. This is only a test and + should not be considered the complete answer to everyone's + security woes. Just implementing a policy and ignoring it + never works and could be disastrous in a production + environment. + + Before beginning this process, the + multilabel option must be set on each file + system as stated at the beginning of this chapter. Not doing + so will result in errors. While at it, ensure that the + net-mngt/nagios-plugins, + net-mngt/nagios, and + www/apache22 ports are all + installed, configured, and working correctly. + + + Create an insecure User Class + + Begin the procedure by adding the following user class + to the /etc/login.conf file: + + insecure:\ +:copyright=/etc/COPYRIGHT:\ +:welcome=/etc/motd:\ +:setenv=MAIL=/var/mail/$,BLOCKSIZE=K:\ +:path=~/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin +:manpath=/usr/share/man /usr/local/man:\ +:nologin=/usr/sbin/nologin:\ +:cputime=1h30m:\ +:datasize=8M:\ +:vmemoryuse=100M:\ +:stacksize=2M:\ +:memorylocked=4M:\ +:memoryuse=8M:\ +:filesize=8M:\ +:coredumpsize=8M:\ +:openfiles=24:\ +:maxproc=32:\ +:priority=0:\ +:requirehome:\ +:passwordtime=91d:\ +:umask=022:\ +:ignoretime@:\ +:label=biba/10(10-10): + + And adding the following line to the default user + class: + + :label=biba/high: + + Once this is completed, the following command must be + issued to rebuild the database: + + &prompt.root; cap_mkdb /etc/login.conf + + + + Boot Configuration + + Do not reboot yet, just add the following lines to + /boot/loader.conf so the required + modules will load during system initialization: + + mac_biba_load="YES" +mac_seeotheruids_load="YES" + + + + Configure Users + + Set the root user to the default + class using: + + &prompt.root; pw usermod root -L default + + All user accounts that are not root + or system users will now require a login class. The login + class is required otherwise users will be refused access + to common commands such as &man.vi.1;. + The following sh script should do the + trick: + + &prompt.root; for x in `awk -F: '($3 >= 1001) && ($3 != 65534) { print $1 }' \ + /etc/passwd`; do pw usermod $x -L default; done; + + Drop the nagios and + www users into the insecure class: + + &prompt.root; pw usermod nagios -L insecure + &prompt.root; pw usermod www -L insecure + + + + Create the Contexts File + + A contexts file should now be created; the following example + file should be placed in + /etc/policy.contexts. + + # This is the default BIBA policy for this system. + +# System: +/var/run biba/equal +/var/run/* biba/equal + +/dev biba/equal +/dev/* biba/equal + +/var biba/equal +/var/spool biba/equal +/var/spool/* biba/equal + +/var/log biba/equal +/var/log/* biba/equal + +/tmp biba/equal +/tmp/* biba/equal +/var/tmp biba/equal +/var/tmp/* biba/equal + +/var/spool/mqueue biba/equal +/var/spool/clientmqueue biba/equal + +# For Nagios: +/usr/local/etc/nagios +/usr/local/etc/nagios/* biba/10 + +/var/spool/nagios biba/10 +/var/spool/nagios/* biba/10 + +# For apache +/usr/local/etc/apache biba/10 +/usr/local/etc/apache/* biba/10 + + This policy will enforce security by setting restrictions + on the flow of information. In this specific configuration, + users, root and others, should never be + allowed to access Nagios. + Configuration files and processes that are a part of + Nagios will be completely self + contained or jailed. + + This file may now be read into our system by issuing the + following command: + + &prompt.root; setfsmac -ef /etc/policy.contexts / +&prompt.root; setfsmac -ef /etc/policy.contexts / + + + The above file system layout may be different depending + on environment; however, it must be run on every single file + system. + + + The /etc/mac.conf file requires + the following modifications in the main section: + + default_labels file ?biba +default_labels ifnet ?biba +default_labels process ?biba +default_labels socket ?biba + + + + Enable Networking + + Add the following line to + /boot/loader.conf: + + security.mac.biba.trust_all_interfaces=1 + + And the following to the network card configuration stored + in rc.conf. If the primary Internet + configuration is done via DHCP, this may + need to be configured manually after every system boot: + + maclabel biba/equal + + + + Testing the Configuration + + + MAC Configuration Testing + + + Ensure that the web server and + Nagios will not be started + on system initialization, and reboot. Ensure the + root user cannot access any of the files + in the Nagios configuration + directory. If root can issue an &man.ls.1; + command on /var/spool/nagios, then something + is wrong. Otherwise a permission denied error + should be returned. + + If all seems well, Nagios, + Apache, and + Sendmail can now be started in a way + fitting of the security policy. The following commands will + make this happen: + + &prompt.root; cd /etc/mail && make stop && \ +setpmac biba/equal make start && setpmac biba/10\(10-10\) apachectl start && \ +setpmac biba/10\(10-10\) /usr/local/etc/rc.d/nagios.sh forcestart + + Double check to ensure that everything is working + properly. If not, check the log files or error messages. Use + the &man.sysctl.8; utility to disable the &man.mac.biba.4; + security policy module enforcement and try starting everything + again, like normal. + + + The root user can change the security + enforcement and edit the configuration files without fear. + The following command will permit the degradation of the + security policy to a lower grade for a newly spawned + shell: + + &prompt.root; setpmac biba/10 csh + + To block this from happening, force the user into a range + via &man.login.conf.5;. If &man.setpmac.8; attempts to run + a command outside of the compartment's range, an error will + be returned and the command will not be executed. In this + case, setting root to + biba/high(high-high). + + + + + + User Lock Down + + This example considers a relatively small, fewer than fifty + users, storage system. Users would have login capabilities, and + be permitted to not only store data but access resources as + well. + + For this scenario, the &man.mac.bsdextended.4; mixed with + &man.mac.seeotheruids.4; could co-exist and block access not + only to system objects, but to hide user processes as + well. + + Begin by adding the following line to + /boot/loader.conf: + + mac_seeotheruids_load="YES" + + The &man.mac.bsdextended.4; security policy module may be + activated through the use of the following rc.conf + variable: + + ugidfw_enable="YES" + + Default rules stored in + /etc/rc.bsdextended will be loaded at system + initialization; however, the default entries may need + modification. Since this machine is expected only to service + users, everything may be left commented out except the last + two. These will force the loading of user owned system objects + by default. + + Add the required users to this machine and reboot. For + testing purposes, try logging in as a different user across two + consoles. Run the ps aux command to see if + processes of other users are visible. Try to run &man.ls.1; on + another users home directory, it should fail. + + Do not try to test with the root user + unless the specific sysctls have been modified + to block super user access. + + + When a new user is added, their &man.mac.bsdextended.4; + rule will not be in the ruleset list. To update the ruleset + quickly, simply unload the security policy module and reload + it again using the &man.kldunload.8; and &man.kldload.8; + utilities. + + + + + Troubleshooting the MAC Framework + + + MAC Troubleshooting + + + During the development stage, a few users reported problems + with normal configuration. Some of these problems + are listed below: + + + The <option>multilabel</option> option cannot be enabled on + <filename>/</filename> + + The flag does not stay + enabled on my root (/) partition! + + + It seems that one out of every fifty users has this + problem, indeed, we had this problem during our initial + configuration. Further observation of this so called + bug has lead me to believe that it is a + result of either incorrect documentation or misinterpretation + of the documentation. Regardless of why it happened, the + following steps may be taken to resolve it: + + + + Edit /etc/fstab and set the root + partition at for read-only. + + + + Reboot into single user mode. + + + + Run tunefs + on /. + + + + Reboot the system into normal mode. + + + + Run mount + / and change the + back to in /etc/fstab + and reboot the system again. + + + + Double-check the output from the + mount to ensure that + has been properly set on the + root file system. + + + + + + X11 Server Will Not Start After <acronym>MAC</acronym> + + After establishing a secure environment with + MAC, I am no longer able to start + X! + + This could be caused by the MAC + partition policy or by a mislabeling in + one of the MAC labeling policies. To + debug, try the following: + + + + Check the error message; if the user is in the + insecure class, the + partition policy may be the culprit. + Try setting the user's class back to the + default class and rebuild the database + with the cap_mkdb command. If this + does not alleviate the problem, go to step two. + + + + Double-check the label policies. Ensure that the + policies are set correctly for the user in question, the + X11 application, and + the /dev + entries. + + + + If neither of these resolve the problem, send the + error message and a description of your environment to + the TrustedBSD discussion lists located at the + TrustedBSD + website or to the &a.questions; + mailing list. + + + + + + Error: &man..secure.path.3; cannot stat <filename>.login_conf</filename> + + When I attempt to switch from the root user + to another user in the system, the error message + _secure_path: unable to state .login_conf appears. + + This message is usually shown when the user has a higher + label setting then that of the user whom they are attempting to + become. For instance a user on the system, + joe, has a default label of + . The root user, + who has a label of , cannot view + joe's home directory. This will happen + regardless if root has used the + su command to become joe, + or not. In this scenario, the Biba integrity model will not + permit root to view objects set at a lower + integrity level. + + + + The <username>root</username> username is broken! + + In normal or even single user mode, the + root is not recognized. The + whoami command returns 0 (zero) and + su returns who are you?. + What could be going on? + + This can happen if a labeling policy has been disabled, + either by a &man.sysctl.8; or the policy module was unloaded. + If the policy is being disabled or has been temporarily + disabled, then the login capabilities database needs to be + reconfigured with the option being + removed. Double check the login.conf + file to ensure that all options have + been removed and rebuild the database with the + cap_mkdb command. + + This may also happen if a policy restricts access to the + master.passwd file or database. Usually + caused by an administrator altering the file under a label + which conflicts with the general policy being used by the + system. In these cases, the user information would be read + by the system and access would be blocked as the file has + inherited the new label. Disable the policy via a + &man.sysctl.8; and everything should return to normal. + + + -- cgit v1.2.3