Creating the development environment_SELinux Cookbook-QQ阅读男生历史网

上QQ阅读APP看书，第一时间看更新

Creating the development environment

We will now create a development environment in which the SELinux policies and upstream project code as well as the functions we use to easily query the SELinux policies will be stored. This environment will have the following three top-level locations:

local/: This location contains the SELinux rules that are local to the system and not part of a cooperatively developed repository (that is, where other developers work)
centralized/: This location contains checkouts of the various repositories used in the development environment
bin/: This location contains the supporting script(s) we will use to query the policy sources as well as troubleshoot the SELinux issues

In this exercise, we will also populate the centralized/ location with a checkout: the SELinux policy tree that is used by the current system.

Getting ready

Look for a good location where the development environment should be stored. This usually is a location in the user's home directory, such as /home/staff/dev/selinux/. Whenever this book references a location with respect to the development environment, it will use the ${DEVROOT} variable to refer to this location.

Another piece of information that we need is the location of the repository that hosts the SELinux policies of the current system. This location is distribution specific, so consult the distribution site for more information. At the time of writing this book, the policies for Gentoo Linux and Fedora can be found at the following locations:

Whenever version control is used, we will use git in this book. Other version control systems exist as well, but this too is outside the scope of this book.

How to do it…

To create the development environment used in this book, perform the following steps:

Create the necessary directories:

~$ cd ${DEVROOT}
~$ mkdir local centralized bin

Create a checkout of the distributions' SELinux policy tree (which, in this example, is based on the Gentoo Linux repository):
```
~$ cd ${DEVROOT}/centralized
~$ git clone git://git.overlays.gentoo.org/proj/hardened-refpolicy.git
```
Create a git repository for the policies that we will develop throughout this book:
```
~$ cd ${DEVROOT}/local
~$ git init
```
Add the functions.sh script, which is available through the download pack of this book, to the ${DEVROOT}/bin/ location.

Edit the .profile, .bashrc, or other shell configuration files that are sourced when our Linux user logs on to the system, and add in the following code:

# Substitute /home/staff/dev/selinux with your DEVROOT
DEVROOT=/home/staff/dev/selinux
# Substitute the next location with your distributions' policy checkout
POLICY_LOCATION=${DEVROOT}/centralized/hardened-refpolicy/
source ${DEVROOT}/bin/functions.sh

Log out and log in again, and verify that the environment is working by requesting the definition of the files_read_etc_files interface:

~$ seshowif files_read_etc_files
interface(`files_read_etc_files',`
 gen_require(`
 type etc_t;
 ')

 allow $1 etc_t:dir list_dir_perms;
 read_files_pattern($1, etc_t, etc_t)
 read_lnk_files_pattern($1, etc_t, etc_t)
')

How it works…

The setup of the development environment helps us deal with policy development for further recipes. The checkout of the distributions' SELinux policy tree is to query the existing policy rules while developing new policies. SELinux does not require to have the policy sources available on a system (only the compiled binary SELinux policy modules and parts of the SELinux policy rules, which can be used by other policy modules). As a result, default installations usually do not have the policy rules available on the system.

By having the checkout at our disposal, we can review the existing SELinux policy files and happily use examples from it for our own use. A major user of this checkout is the functions.sh script, which uses the ${POLICY_LOCATION} variable to know where the checkout is hosted. This script provides several functions that we'll use throughout this book; they will also help in querying the sources.

By sourcing this functions.sh script during log on, these functions are readily available in the user's shell. One of these functions is the seshowif function, which displays the rules of a particular interface. The example given shows the definition of the files_read_etc_files interface, which we used to validate that our setup is working correctly.

The functions.sh script can also work with the interface files that are available through /usr/share/selinux/devel/ (on Fedora/Red Hat systems), making the checkout of the policy repository optional if the user does not need access to the complete policy rules. The policy location defined then is as follows:

export POLICY_LOCATION=/usr/share/selinux/devel/

There's more...

Next to the distributions' SELinux policy tree, one can also use the reference policy SELinux tree. This is the upstream project that most, if not all, Linux distributions use as the source of their policies. It has to be said though that the reference policy often lags behind on the policy repositories of the individual distributions, as it has stricter acceptance criteria for policy enhancements.

It also doesn't hurt to check out the SELinux policy repositories of other distributions. Often, Linux distributions first do SELinux policy updates on their own repository before pushing their changes to the reference policy (which is called upstreaming in the free software development community). By looking at other distributions' repositories, developers can easily see if the necessary changes have been made in the past already (and are thus more likely to be correct).