Section 11.2. Strict Example Policy
11.2. Strict Example PolicyThe strict example policy is the longest-lived version of the example policy. It is largely maintained and updated via the NSA and FC mail lists, but with contributions from other distributions, too. Both NSA and Red Hat maintain versions of the strict example policy, which are essentially the same source tree. You can obtain a version of this policy both from the NSA SELinux project page (http://selinux.sourceforge.net) or from Red Hat for FC. If your system has strict example policy sources installed (see Appendix A, "Obtaining SELinux Sample Policies"), you should be able to see the sources in /etc/selinux/strict/src/policy/. The examples from earlier in this book are from a version of the strict example policy. Our overview is based on the FC4 version of the strict example policy; we encourage you to download the latest versions and use that as a baseline if you choose to use this policy version. The strict example policy builds a complete policy source file (policy.conf) using the source module method described in Chapter 3, "Architecture." Recall that source modules use a combination of scripts and macros to create higher-level constructs and produces a single, monolithic policy file (see Figure 11-1). Source modules make extensive use of macros using m4, which is a flexible and powerful macro tool. Figure 11-1. Build and load process for SELinux policy using the example policy The strict policy Makefile supports a number of build targets. The command make policy compiles the entire policy and builds a binary policy file (for example, ./policy.19). This target is useful for building a policy for testing or for installation on another system. The command make policy.conf constructs a complete policy source file (./policy.conf) but will not compile the policy source. This is useful if we want to construct a complete policy source for analysis (for example, using apol). The command make install builds the binary policy and installs it and all supporting policy management files. In the case of strict policy, the default installation directory is in /etc/selinux/strict/. This command installs the new policy but does not load it into the kernel. You would need to reboot the machine or use the make load command. Finally, the make relabel command applies the security contexts to all files in the system. In general, we would relabel only the entire system during initial install and/or after we load an entirely new policy. Note The primary method for relabeling an entire filesystem is no longer using make relabel from the policy source tree. Instead, the current methods of relabeling the entire system are to use either the fixfiles relabel command or the touch /.autorelabel command and reboot the systems. These two methods can be done with only the file contexts configuration installed and not the entire policy source. 11.2.1. Overview of Policy Source File StructureFor this chapter, we examine the strict example policy sources from FC4; depending on the version of the system you are using, there may be some differences. All filenames are from the policy source root directory (for example, /etc/selinux/strict/src/policy). You will find various levels of comments within each file and the ./README file at the top-level for additional information. In this section, we give you a guided tour of the key files and directories, along with insights to their purposes and uses. Our goal is to give you a head start in understanding the file structure; only experience will allow you to fully understand them. 11.2.1.1. Object Class and Permission DefinitionsAs discussed in Chapter 4, "Object Classes and Permissions," object classes and their associated permission sets are defined in the policy language. For the example policy, the directory ./flask/ contains these definitions. The Flask definitions are essentially static for all policies and should not be changed. Kernel source header files are automatically generated from these files, because the kernel and the policy must both agree on the set of object classes and associated permissions. The principal files in this directory are as follows:
In addition, this directory also contains several shell scripts that are used to construct the kernel header files. Warning In general, you would not edit any of the files in the ./flask/ directory. These files must correspond with kernel header files. Unless you are positive you know what you are doing, which would imply familiarity with the kernel SELinux Linux Security Module (LSM) source code, leave this directory alone. 11.2.1.2. Domain Types and Policy RulesThe primary policy modules for an example policy are kept in the ./domains/ directory. There are two files and two subdirectories in this directory: ./domains/admin.te ./domains/user.te These two files (the .te is for type enforcement) define domain types of user login sessions. These "user domains" are unlike most other domain types in that they are not associated with a specific program, but rather are the default domain types for classes of users. The file admin.te defines the domain type sysadm_t, which is the most powerful user domain type. Although sysadm_t has nowhere near the level of privilege, this domain type is the SELinux analogue to root. The file user.te defines less-privileged user domain types, user_t and staff_t. Both of these types have limited privileges and are intended for "ordinary users." The primary difference between the two is that staff_t is able to transition its role and domain type to the more privileged sysadm_t. These files also define a number of Booleans that are used to provide runtime policy configuration options. ./domains/program/ ./domains/misc/ These two directories contain the policy source modules for the strict example policy. The program/ directory is where most of the modules are located, typically one file per domain type (or set of related domain types). Each policy module is contained in a .te file. Each module has a separate file contexts file that identifies how file-related objects should be labeled with security context for those objects associated with the module's types. We discuss file contexts later in this chapter. The misc/ directory contains a small number of modules that are not the typical domain types (for example, the type for the kernel: kernel_t) and do not have related .fc (file context) files. There is little difference between the two directories in terms of functionality; in general, you should add any new module to the program/ directory. The ./domains/ directory is organized to support a coarse level of policy customization. Both policy module directories have an unused/ directory (for example, ./domains/program/unused for the primary module directory). The .te module files in those unused directories will not be included in the policy build, nor will the associated file contexts. Therefore, we can exclude unneeded policy statements from the policy we build by moving unnecessary policy modules to the unused/ directory. We examine a policy module later in this chapter. Warning Dependencies are not well managed in the example policy. Therefore, as you move policy modules in and out of the unused directory, you might find other policy modules that depend upon the newly used/unused module resulting in build errors. 11.2.1.3. Unaffiliated Resource TypesBesides the policy modules described previously, most of the rest of the type declarations for a strict example policy are contained in the ./types/ directory. The files in this directory generally (but not always) just define types and not rules to access the types. These types are primarily passive objects of the kernel and key userspace services and are not active domain types. You may need to change these files, especially if you want to change the policy associated with certain kernel resources (for example, networking). The files in this directory are as follows:
11.2.1.4. Miscellaneous Top-level Files and DirectoriesAt the top-level directory, a number of files capture some of the less-frequently changed and used policy components. Here we list these files and the conventions expected for each file:
These files are fairly simple and straightforward in their purpose. You will find that you will likely change them little if you are just trying to use and adapt the policy for your application. 11.2.1.5. Security Context LabelingOne of the great challenges with using SELinux, besides writing a good TE policy, is ensuring that all the various object instances (files, directories, ports, network interfaces, and so on) are labeled with the correct type for the current policy. After you have a properly compiled TE policy, many of your debugging problems will be related to improperly labeled objects. We discussed the mechanisms and issues for object labeling in Chapter 10. Next we discuss how object labeling is managed in the strict example policy source files. Several files in the policy source root directory address some of the security context labeling for a system, in particular those context labeling statements that are part of the policy language proper:
These files address all object labeling concerns except the most complex issue (that is, labeling of all the file-related objects for the various disk-based filesystems). Disk-based object labeling is called file context labeling, as we discussed in Chapter 10. To create an initial file context labeling policy, we have the directory ./file_contexts/. This directory contains a number of files that together with the files in ./file_contexts/misc/ are used to create a complete file contexts file useable to label and relabel all disk-based filesystems. One directory, ./file_contexts/program/, is directly related to the similarly named module directory in the ./domains/program/ directory. This directory contains .fc files (fc for file contexts) that have the file context statements associated with the like named module file from the ./domains/program/ directory. When building a complete file contexts file, only those .fc files whose associated policy module .te file are currently "used" (that is, not in the unused directory under ./domains/program/) are included. In this way, you can manage both the TE file (.te) and the associated security context file (.fc) using the same method. The file ./file_contexts/types.fc defines labeling statements not specific to a program module (for example, how to label file in /etc/). This file is always included in a strict example policy build. The file ./file_contexts/distro.fc is similar to types.fc except that it contains configuration options specific to a particular distribution. The file ./file_contexts/home_dir_template contains file labeling instructions for files and directories in a user home directory. This file is a template so that users' home directories can be labeled depending on users' roles. This file is also installed and used when managing the policy in an operational system (see Chapter 13, "Managing an SELinux System"). These files, along with the "used" .fc files, are concatenated during the build process to make a single file_contexts file. This file is what the setfiles program (and other related programs that use the matchpathcon(3) library) uses to set and fix disk-based object labels as discussed in Chapter 10. 11.2.1.6. Application Configuration FilesThe directory ./appconfig/ contains a set of files that specify security context information that various services and applications use in running systems. These files are installed in the operational policy directory (for example, /etc/selinux/strict/contexts). We discuss the purpose of these files in Chapter 13. 11.2.2. Examining an Example Policy ModuleTo help understand the strict example policy and how it manages the process of building a policy, let's examine an example policy module. In particular, let's look at the policy module for the ping program. A partial listing of this module is shown in Listing 11-1. You should find a similar module in ./domains/program/ping.te or ./domains/program/unused/ping.te. Listing 11-1. Policy Module for Ping from the Strict Example Policy (ping.te)
Notice that lines 4, 8 and 9, 12, 18 through 20, and 22 contain macros rather than policy language statements. Macros using the m4 macro processor are common in example policy source files. These macros, some of which we examine in this chapter, cause several lines of policy language to be included into the module source file during the policy compile process. 11.2.2.1. Defining Types for a DomainLines 1 and 5 define two types, ping_t and ping_exec_t. The type ping_t is the domain type for the ping program, and the type ping_exec_t is the type associated with the ping executable file on disk. Having a domain type and associated file executable type appended with _exec_t is a common convention. As you can see, several attributes are associated with each type. For example, the attribute domain is associated with the type ping_t; all domain types have this attribute in the strict example policy. Lines 2 and 3 associate the ping domain type with two roles: sysadm_r, which is the privileged user role; and system_r, which is the role for system processes. Line 4 also associates the ping domain type with a role, but this time using a macro in_user_role(). We can find this macro defined in ./macros/user_macros.te, as in the following: define(`in_user_role', ` role user_r types $1; role staff_r types $1; ') As you can see, this macro associates the domain type with two additional roles: user_r, which is the role for ordinary users; and staff_r, which is the unprivileged role for users authorized to change roles to the privileged sysadm_r role. Note M4 macros use string substitution for argument. So, for example, $1 in the macro definition refers to the first supplied argument, $2 to the second, and so on. As we see in line 4 of the ping module, the in_user_role macro is invoked with this line: in_user_role(ping_t) This invocation provides a single argument ping_t, which is substituted for $1.
11.2.2.2. Specifying Domain Transition RulesNow look at lines 8 and 9, where we have two invocations of the domain_auto_trans() macro. This macro is probably the most common macro in the strict example policy as it defines the standard rules to allow a domain transition as we discussed in Chapter 2, "Concepts." You can find the definition of this macro in ./macros/core_macros.te. The actual macro is quite short as it calls another macro, domain_trans(), which is defined in the same file: # $1 is original domain, $2 is executable file type, $3 is new domain define(`domain_auto_trans',` domain_trans($1,$2,$3) type_transition $1 $2:process $3; ') The domain_auto_trans() macro grants the necessary permissions to allow a domain transition (by calling the domain_trans() macro) and makes the transition happen automatically by default via a type_transition rule. If we further examine the domain_trans() macro, we see many more rules that mostly address permissions necessary for interprocess communication (IPC) between the parent and child process types that results from a domain transition. However, this macro also contains the three minimally required allow rules required for a domain transition as discussed in Chapter 2, specifically the following: # key rules from domain_trans macro # $1 is original domain, $2 is executable file type, $3 is new domain define(`domain_trans',` allow $1 $3:process transition; # old domain can trans to new domain allow $1 $2:file { read x_file_perms }; # # old domain execute file type allow $3 $2:file entrypoint; # new domain can be entered from file type # remaining domain_trans rules not shown... ')Notice that the second rule has read and x_file_perms in the permission field. Although read is a permission for the file object class, x_file_perms is not. Instead, it is a another type of m4 macro that is replaced with a set of permissions that generally represent "file execute" permissions. We find this macro defined in ./macros/core_macros.te as follows: define(`x_file_perms', `{ getattr execute }')So looking back at lines 8 and 9 from the ping module, we see that the privileged administrator domain type sysadm_t and the init process script domain initrc_t both are given access to transition into the ping_t domain, which in effect means they can run the ping program. These two macros each result in many policy statements via macro processing as we have illustrated. 11.2.2.3. Conditional Policy ExampleStarting on line 10, we see an example of a conditional policy block. Line 10 defines the Boolean user_ping, and lines 11 through 16 contain the conditional clause that uses this Boolean. In this case, the conditional policy statements use a Boolean variable to control whether unprivileged user domains are allowed to use the ping program. This is accomplished primarily via the conditional call to the domain_auto_trans() macro on line 12. Notice that the originating domain for the transition is an attribute (unpriv_userdomain) rather than a type as in lines 8 and 9. This means that all types with that attribute are given the set of permissions that grant a domain transition into ping_t. There is no easy way to determine what those types are in the policy source files; generally, we are expected to know what that attribute represents and expect that none of the policy source files violate this expectation. The only practical way to determine the types associated with an attribute is to use the apol tool discussed earlier in this book. 11.2.2.4. Network and Other Access for PingLooking again at the ping module, line 18 invokes a macro that grants the ping_t domain permissions needed to use and link with shared libraries. Lines 19 through 24 provide various other access the ping domain will need to network and system resources. Many of these lines invoke macros that you should explore further at your leisure. For example, take a closer look at line 19 and the can_network_client() macro, which is defined in ./macros/network_macros.te. Notice that this macro gives nearly all access to do most types of client networking over all available network interfaces. This is a coarse level of permission, and SELinux will allow you to be much more explicit in network control. However, this type of macro is common in general-purpose policies such as the example policy (although later versions of the example policy have attempted to improve this). As you can see lines 20 through 22 and line 27 provide additional network access over and above what can_network_client() provides. Take some time to further explore all of these macros. Tip To examine what a macro does, you must first find it. The easiest way to do this is to use grep from the policy macro directory ./macros. For example, to find the definition of the uses_shlib macro from line 18 of the ping module, do the following: # cd /etc/selinux/strict/src/policy/macros # grep -r uses_shlib * | grep define global_macros.te:define('uses_shlib',' Let's look at line 30 of the ping module. Here we see the ping_t domain type is given access to itself using the self keyword for the capability object class. This object class controls the Linux capabilities; it only ever makes sense to give domains permissions to itself for this object class. In this case, we are giving ping_t permission to use the privileged capabilities necessary to perform raw networking and to use the setuid kernel call to change user IDs (that is, in this case to change to root). The remaining allow rules in lines 33 and 34 give the ping_t domain permission to interact with terminal devices for display of output. Neglecting to provide access for terminal devices is a common mistake. 11.2.2.5. Audit RulesFinally, we have a couple examples of dontaudit rules. These rules are used to mask out access denials we expect that do not prevent ping from functioning. It is not uncommon for Linux applications to attempt to use more permission than they need. Rather than grant them this excessive access, it is better to let the access denial occur, but filter out the resulting audit message using dontaudit rules so that the audit log is not polluted. 11.2.2.6. File Security Contexts LabelingThe final component of the ping module is the file context statements used to correctly label the ping-related files and directories. You can find the ping file contexts in ./policy/file_contexts/program/ping.fc. For example: /bin/ping.* -- system_u:object_r:ping_exec_t This file contexts specification causes the setfiles utility to label any file in /bin/ that starts with ping (on our system that includes ping and ping6, both versions of the standard ping program) with the specified security context which includes the file executable type ping_exec_t. 11.2.3. Build Options for Strict Example PolicyThe strict example policy source tree provides a few basic configuration options that enable us to control the contents of the kernel policy. These configuration options allow some control over the content of the resulting policy without having to write policy statements. 11.2.3.1. Configuring Policy ModulesWe can control which policy modules are included in the policy by using the unused/ directories discussed previously. So, for example, if we did not want the ping policy module included in our policy, we would move the file ping.te from ./domains/program/ to ./domains/program/unused/. This will prevent ping.te (and the associated ping.fc) file from being included in the policy build. You may find yourself removing many modules to customize the policy for your particular installation. Although extraneous policy modules (that is, for programs that are not installed) will generally not impact the operation of the system, it will add memory usage inside the kernel. In some cases (for example, a Web browser), the absence of a policy is less desirable because the application would run in the user's domain with more access than it would in a more restrictive browser domain. Including unwanted policy modules also creates the risk that software may accidentally be installed and then have the privilege to run. For example, suppose we did not want any user to run the ping program, so we did not install the software, but we forgot to remove the ping policy module. If, at some later date, we installed a software package that installed its own version of ping (because it needed it and its installation script saw that it was not installed), all of a sudden our users have access to ping! If we had removed the ping policy module in our original policy, when the software package installed its ping program, users would not be able to use the program because there would be no domain ping_t defined. (That is, it would likely get a common utility label like bin_t that would allow users to execute it in their domain, but not in the more privileged ping_t domain.) 11.2.3.2. Enabling Optional MLS FeaturesWe have mentioned throughout this book the optional capabilities for MLS policies and the related multicategory security (MCS) configuration that uses the MLS optional features. By default, the strict example policy configuration does not enable either of these configurations for the MLS features. To use the MLS features, the policy must be compiled with a special option to tell the kernel that MLS is being used. More important, all security contexts must be extended with the required MLS sensitivities, as discussed in Chapter 8. The strict example policy Makefile has configuration options to automate these steps. If you look near the top of the Makefile (./Makefile), you will see the following: # Set to y if MLS is enabled in the policy. MLS=n # Set to y if MCS is enabled in the policy MCS=n Setting either of these flags tells the checkpolicy compiler to build a policy that has the optional MLS features enabled. When this policy is loaded into the kernel, this will in turn tell the kernel to use the optional MLS features for access enforcement. You should not enable both of these options as they are mutually exclusive. Enabling either the MLS or the MCS option only builds a policy file that has MLS enabled. It will not ensure that all the various security context specifications are extended to include the extended MLS security context information. The strict example policy comes with make targets that perform a basic reconfiguration of all security contexts: make mlsconvert and make mcsconvert. These targets will change all security contexts throughout the policy; however, the MLS portion of the security context will generally be inadequate for a real MLS system. More than likely, you will have to build your own file contexts that label all files, directories, ports, network interfaces, and so on as appropriate for your MLS applications. For example, make mls will change ping.te to this: /bin/ping.* -- system_u:object_r:ping_exec_t:s0 See Chapter 8 for more information on MLS security contexts. Warning Using either make mlsconvert or make mcsconvert will permanently change the security context specifications throughout the example policy source files. There is no mechanism for returning to the original state. Therefore, you are advised to make a copy of the source tree before trying this feature. Both of these configuration options will set the corresponding MLS=y or MCS=y option in the Makefile. You do not need to manually set these options if you use these make targets. 11.2.3.3. Build-Time TunablesIn the directory ./tunables/ are two files, distro.tun and tunable.tun, that allow us to enable/disable configuration options that are built in to the various policy modules of the strict example policy. The distro.tun file is used for distribution-specific configuration options. For example, on our FC4 system, the file contains the following: define('distro_redhat') dnl define('distro_suse') dnl define('distro_gentoo') dnl define('distro_debian')This file indicates that the distro_redhat options are enabled and not the various other distributions. (dnl is a m4 command meaning "discard up to newline.") The tunables.tun file has similar options that we can configure to be on or off controlling more general (that is, nondistribution specific) options. Throughout the policy modules, statements are included within m4 ifdef clauses that will or will not be included in the policy depending on whether a tunable is enabled or disabled. For example, in lines 39 through 41 of the ping module in Listing 11-1, we have a dontaudit rule included within ifdef('hide_broken_symptoms'), which is an m4 ifdef statement. If you look in ./tunables/tunable.tun, you see will see this option and whether it is enabled. |
EAN: 2147483647
Pages: 154