SELinux Policy Management Server - HOWTO

Introduction

This document will provide an introduction for installing and running the SELinux policy management server, including a brief overview of creating policy for the policy management server objects. It is assumed that the reader is familiar with binary policy modules and SELinux in general. The policy management server is currently in active development and is still considered experimental. It should be relatively stable, but it is likely that you will encounter bugs. Additionally, it is likely that the policy management server will change in the future, including the object classes and permissions.

Installation

Installing the policy management server requires, unfortunately, several large changes to your system including the installation of updated SELinux libraries. These changes can easily render your system unusable; please only continue if you are experienced with administering SELinux systems.

Note: the policy management server rpms may be used with Fedora 8 and later but they must be installed using "rpm --force" since fedora 8 ships with a newer version of the SELinux toolchain.

First download and unpack the rpm tarball:

# wget http://oss.tresys.com/files/policy-server/pms-rpms.tar.gz

Then unpack and install the rpms. The --force option must be used on Fedora 8 which ships with a newer version of the packages.

# tar zxf pms-rpms.tar.gz

# cd i386

# rpm -i --force *rpm

The reference policy with updated object class definitions and a sample policy module (iso_dom) can be downloaded at http://oss.tresys.com/files/policy-server/refpolicy-pms-support.tgz

Using the Policy Management Server

Installing the Configuration Files

The policy server has a variety of configuration options that are loaded from a configuration file called pms.conf located in /etc/selinux. An example pms.conf file will be installed. Edit pms.conf with your preferences. It is highly recommended to enable debugging information at this phase. Of particular interests are the options fork-daemon and log-level. Set their values to false and 4, respectively.

Next edit /etc/selinux/semanage.conf and add the following two lines:

save-linked = true

Then, run:

# semodule -Bn

which will rebuild the policy, retaining the previous version as well as the linked base module.

You are now ready to change to the policy server store. Edit /etc/selinux/semanage.conf and make the following change:

#module-store = direct
module-store = /var/run/pms

If the semanage.conf changes were correct, semodule should no longer be able to read a module list:

# semodule -l
semodule:  Could not connect to policy handle

Running the Policy Server

You are now ready to run the policy management server for the first time:

# pms
Setting log level to 4
Skipping network socket connection.
Policy server ready and waiting for connections

Now that the policy server is running, you can read the module list using the pms back end.

# semodule -l

Labelling Policy Components

As described in the high level design document, all policy components are labeled with normal SELinux types. This file is located at /etc/selinux/policy_contexts. The syntax for labeling policy components is:

[component type] [selinux type] [selinux context]

The valid component types are: class, role, type, user, bool, and attribute. For the purposes of metapolicy verification, attributes are distinct from types. For example labeling apache types could look like.

type httpd_staff_script_t      	system_u:object_r:httpd_staff_types_t
type httpd_staff_htaccess_t  	system_u:object_r:httpd_staff_types_t
type httpd_staff_content_t     	system_u:object_r:httpd_staff_types_t

Note: the context must be valid for the policy management server to work properly. In the above example the type httpd_staff_types_t must be added to the policy in order to work.

Building a Test Module

If you were to now install binary modules with an enforcing policy you would be met with many SELinux denial messages. Test this theory creating a module source file testmod.conf with the following contents:

module testmod 1.0;

require {
   class file { read };
}

type testmod1_t;
type testmod2_t;
role testmod_r types { testmod1_t testmod2_t };

allow testmod1_t testmod2_t : file { read };

Compile, package, and install the module:

# checkmodule -m -M testmod.conf -o testmod.mod
checkmodule:  loading policy configuration from test-module.conf
checkmodule:  policy configuration loaded
checkmodule:  writing binary representation (version 6) to testmod.mod

# semodule_package -o testmod.pp -m testmod.mod

# setenforce 1

# semodule -v -i testmod.pp
Attempting to install module 'testmod.pp':
Failed.

Switch to the policy-server terminal. You should see an error message similar to the following:

sepsavc:  denied  { add } for  scontext=root:system_r:semanage_t:s0-s0:c0.c1023 tcontext=system_u:object_r:unlabeled_t:s0 tclass=policy.type

sepsavc stands for SELinux Policy Server AV Cache. The scontext comes from the client program's context; on a Fedora Core 3 system with targeted policy it will be unconfined_t.

Allowing Policy Changes

One needs to write metapolicy statements to grant permissions necessary to install testmod.pp. Instead of adding the appropriate allow rules directly into the base module, instead create a file named allow_testmod.conf with the following statements:

module allow_testmod 1.0;

require {
  type policy_t, unconfined_t;
  class policy.role { add use };
  class policy.type { add remove use };
}

allow unconfined_t policy_t : policy.role { add use };
allow unconfined_t policy_t : policy.type { add use };

If your semodule is not running in the domain unconfined_t then change the above allow statements as appropriate. Compile and install this module; you will have to switch to permissive mode first:

[root@foo tmp]# checkmodule -M -m allow_test.conf -o allow_test.mod
checkmodule:  loading policy configuration from allow_test.conf
checkmodule:  policy configuration loaded
checkmodule:  writing binary representation (version 6) to allow_test.mod

# semodule_package -o allow_test.pp -m allow_test.mod

# setenforce 0

# semodule -v -i allow_test.pp
Attempting to install module 'allow_test.pp':
Ok.

Now try to install the testmod module in enforcing mode. The newly added allow rules should permit the installation to proceed:

# setenforce 1

# semodule -v -i testmod.pp
Attempting to install module 'testmod.pp':
Ok.

You can verify that both modules exist by calling semodule with a -l option.

# semodule -l
allow_testmod   1.0
testmod 1.0

Practical example of meta policy

As of now there is no practical example of meta-policy on the current system. We will write a small practical example meta policy for the password program and related objects.

The policy for the password program and its objects is written to be extreamly strict. But what if policy was updated only in a monolithic manner and no selinux checks on policy changes. One could just load a new policy allowing something like evil_hacker_t domain to modify the password program's objects, namely /etc/shadow. clearly the entire security of SELinux could be circumvented.

But with meta-policy we can enforce MAC on policy objects. The example meta policy could look like the following with the following assumptions that user_admin_t is a policy server client used by an administrator who's only job is to manage users and policy of users of a system. Also Assume that policy objects passwd_t, shadow_t and file are labeled as passwd_type_t, shadow_type_t and file_type_t respectively.

module allow_passwd 1.0;

require {
  type passwd_type_t, shadow_type_t;
  class policy.class { use };
  class policy.type { use };
}

#allow the user_admin_t program to change rules where the password program is the subject and associate it with roles.
allow user_admin_t passwd_type_t : policy.type { use };

#allow user_admin_t to use file object classes in allow, dontaudit and neverallow rules
allow user_admin_t file_type_t : policy.class { use };

#allow user_admin_t to use the shadow type as the target in allow, neverallow and dontaudit rules.
allow user_admin_t shadow_type_t : policy.type { use };

This allows the user management pms client to change rules with passwd_t and shadow_t but not make modifications to apache types. Likewise some apache pms client should not have rules written for it to modify password program subject and objects but should be allowed to modify apache rule sets.