Building a Basic Policy

Introduction

The objective of this section is to show how policy files are constructed, compiled and loaded using the SELinux command line tools and editors such as vi or gedit to produce a usable policy for instructional use only.

A modular (with loadable modules) policy is built without the use of any support macros or make files from the Reference Policy source.

Important Note: While these are simple policies, they are built to support X-Windows therefore an x_contexts file must be installed. This file is required by the X-Windows SELinux object manager.

It is recommended that the Notebook Source file is installed in your $HOME as this contains all the configuration files and source code required to produce the required modules. It also contains README and a simple Makefile for each section.

Overall Objectives

Show how to construct and build a series of loadable modules for use with the base module. This builds into a very simple message filter using a network client / server application and file moving (filter) application (TODO).

Demonstrate simple X-Windows select and paste applications using customised x_contexts files to show the different between standard (as used by the Reference Policy) and polyinstantiation selections using the XSELinux object manager / XACE services.

Build a test application that allows the XSELinux SELinuxGet.. and SELinuxSet.. functions to be tested.

Build Requirements

To be able to build the policy files only standard SELinux utilities are required. However to build the test “C” programs development tools will be required, therefore ensure that the following are installed:

gcc tools to compile and link the test applications (gcc and libgcc packages).

The libselinux library and libselinux-devel packages.

For the X-Windows examples the the following will also be required:

The Xlibpackages libX11, libX11-common and libX11-devel.

For retrieving Xdevice information libXi and libXi-devel.

If the NetLabel module is being built, the NetLabel tools will need to be installed as they are not part of the standard F-12 installation (netlabel_tools).

If the Tresys utilities are used (apol, sechecker etc.), then it is recommended that the policies are built uncompressed by adding the following entry in the semanage.conf file:

bzip-blocksize=0

The Test Policies

Normally SELinux policies are built to deny everything by default, and then enable access as required, however the example policies in this section grant access to everything and then run the test applications in their own domains to isolate them.

The policies built in this section have been tested using the follow sequence:

Will the system load, allow users to logon and run applications in permissive mode - If yes then:

Set the system to enforcing mode by setenforce 1, if still okay then:

Log out users and log in again (as now in enforcing mode, the login may fail), if okay then:

Edit the config file and set SELINUX=enforcing, then reboot the system, if okay then:

Log in users and run applications, if okay then:

Test that the policy meets the security requirements.

If at any stage the load fails, then the repair CD/DVD may have to be used to investigate the cause. Setting the config file SELINUX entry to permissive and investigating the messages and audit logs can be helpful (but not always).

Building the Policy Source Files

There are at least three ways to build a monolithic or base policy source file to experiment with:

Use the samples shown in this section that are valid for F-12. However as SELinux gets updated, the object classes and their associated permissions do change, therefore these samples may not be correct for other versions or distributions.

Rebuild the source files using the flask security_classes, initial_sids and access_vectors files from the Reference Policy source appropriate to the GNU / Linux distribution being used. The policy statements must then be added as necessary.

The buildpolicy script buildpolicy can be used to produce the complete policy automatically using the Reference Policy flask security_classes, initial_sids and access_vectors files.

There is an article SELinux From Scratch that describes a process using a C program and some scripts for building a test policy from the GNU / Linux kernel source tree. This process has since been enhanced and built into the kernel source tree from version 2.6.28, where the following files can be found that describe and build the “make dummy policy”(mdp):

Policy Source File

These are from the Reference Policy (build 20091117) files as they have the correct X-Windows classes:

./policy/flask/security_classes

./policy/flask/access_vectors

./policy/flask/initial_sids

Access Vectors (permissions)

Initial SIDs

MLS Sensitivity, category and level Statements

There are no MLS security level information in the sample policy.

MLS Constraints

There are no MLS constraints in the sample policy.

Policy Capability Statements

There are no policycap statements in the sample policy, however one is added later for a NetLabel exercise using network_peer_controls.

Attributes

There are no attributes in the sample policy.

Booleans

There are no bool statements in the sample policy.

Type / Type Alias

There is only one type: unconfined_t. There are no typealias statements.

Roles

There is only one role: unconfined_r.

Policy Rules

There is one allow rule for each object class (taken from the security_classes file) in the policy that allows unrestricted access to all its permissions as follows:

allow unconfined_t self : class_name *;

Users

There is one user: user_u, for logging on. The system_u user is there to allow objects to be labeled system_u:object_r as in the standard Reference Policy. The system_u user is also required by semanage(8) to add network objects.

Constraints

These are no constraints in the sample policy, however one is added later to show role constraints.

Default SID labeling

These have been taken from the standard Reference Policy build with the security contexts updated. Note that the kernel is labeled unconfined_r and not object_r.

fs_use_xattr Statement

Only the ext3 and ext4 filesystems have been added. If the system being built supports other filesystems then these will need to be added.

fs_use_task and fs_use_trans Statements

These have been taken from the standard Reference Policy build.

genfscon Statements

Only a selection have been taken from the standard Reference Policy build.

portcon, netifcon and nodecon Statements

There are none of these statements in the policy.

Table 1: Policy Components - for the base.conf source file.

Problem Resolution

The following may help with resolving issues when building the examples:

If the files are cut from this document and then pasted into a GNU / Linux editor (such as vi or gedit) as a text file, then there could be a cr at the end of each line. This can cause problems with some compliers such as checkpolicy and checkmodule. To remove the cr use the following command:

cat <file_name> | tr -d \\r >new_file_name

Once the policies etc. have been built and all goes well, the filesystem will relabeled and the new policy loaded during the reboot process, however any errors encountered will probably result in either:

GNU / Linux hanging, in which case the repair disk will be required. To allow GNU / Linux to load, the /etc/selinux/config file should be edited to set either SELINUX=disabled or the SELINUXTYPE= to a known working policy. The reason for the hang can then be investigated (such as correcting the policy source files and/or re-running the build commands).

The policy will be rejected by the kernel and not loaded, GNU / Linux will then load with no policy enabled, giving another chance at fixing the problem (the screen messages will generally give the reason for the rejection).

Building the Base Policy Module

This exercise will build the mandatory base policy module that uses the same policy source file as the monolithic policy discussed above.

The basic steps to produce a simple base test policy are:

Ensure you are logged on as root and SELinux is running in permissive mode (setenforce 0) to perform the build process. It is assumed that the files are built in the ./notebook-source/modular-base-policy directory.

Produce a base policy source file with a text editor (such as vi or gedit) containing the following contents: base.conf.

Produce a base file contexts file with the following contents: base.fc. This will be used to relabel the file system.

Produce a default_contexts file with the folowing contents default_contexts. This will be used to ensure that the correct context is used for the logon process (only really needed when the additional loadable modules are built).

Edit the /etc/selinux/config file and change the entries shown. This will set permissive mode and the policy location that will be loaded on the next re-boot. Note - do not put any spaces after these entries.

SELINUX=permissive
SELINUXTYPE=modular-test

This will set permissive mode so if the policy is too restrictive it will still allow a login at least. The SELinux policy name/location is also added (modular-test). Note do not put any spaces after the entries.

To allow a file system relabeling to be actioned on reboot execute the following command:

touch /.autorelabel

Optionally clear the log files so that they are clear for easier reading:

> /var/log/messages
> /var/log/audit/audit.log

Reboot the system. During the boot process, the file system should be re-labeled.

reboot

Checking the Base Policy Build

Once the system has reloaded, SELinux will be running in permissive mode. Logon as root and use either seaudit, troubleshooter or simply tail in a couple of terminal windows to view the logs:

There should be entries for the boot process in the /var/log/messages file, however the /var/log/audit/audit.log file should only contain entries for the audit daemon, user logon and role change for the logon process.

If the system is working (i.e. it should be stable, load the desktop and allow utilities to be loaded from the menus), then SELinux can be set to enforcing mode by:

setenforce 1

The new policy will be enforced and the only entries in the logs should be about setting enforcing mode.

If the system is unstable when rebooted, then see the Problem Resolution section for a possible resolution.