From Fedora Project Wiki

Revision as of 16:27, 24 May 2008 by Ravidiip (talk | contribs) (1 revision(s))

Configuring Fedora Core To Use The MLS SELinux Policy


Introduction

This document is a quick walk-through of how to install the experimental Multi-Level Security (MLS) policy on a Fedora Core based system. The audience is expected to be familiar with Linux, Fedora Core and to some extent SELinux.

Warnings

It is recommended that you read the entire document first before starting to install the system; special attention should be paid to section 3, "Additional Notes And Troubleshooting". Also, please keep in mind that as part of the installation process you will be loading packages from several unstable YUM repositories which mean you may have to deal with complex RPM dependency issues and system instability.

Installation Guide

Install Fedora Core

The first step is to get a working install of Fedora Core. This document was written using Fedora Core 4 as the base. The steps required to get the MLS policy working on different versions of Fedora Core may be different.

The latest version of Fedora Core can be downloaded here:

Configure The Network

You should have configured the network during the install process, but if you didn't now is the time to get it working. If you need to use a proxy to access the Internet you should create a file, '/etc/profile.d/proxy.sh', which looks like this:

http_proxy="<proxy URL, i.e. http://my.proxy.com:8080>"
HTTP_PROXY="$http_proxy"
export http_proxy HTTP_PROXY

This will cause the environment variables 'http_proxy' and 'HTTP_PROXY' to be set correctly when you use Bash or any other Bourne based shell.

Configure RPM And YUM

YUM is a utility, built on top of RPM, which is used by Fedora to distribute updates and resolve package dependencies. By default your Fedora install should have YUM installed, but a little bit of extra configuration is needed before it is useful for our purposes.

Import The GPG Keys Into The RPM Database

RPM packages can be signed by the packager using GPG to help ensure the integrity of the files. By default YUM on Fedora Core 4 checks the signatures on the RPM packages it installs so you need to have the correct GPG public keys loaded into the RPM database. You can do this with the following command:


Add The Rawhide Repository and LSPP kernel

The next step in configuring YUM is to add bleeding edge development YUM repositories and the LSPP test kernels. You can add the repository by creating two new repository description files:

file /etc/yum.repos.d/fedora-rawhide.repo :

[rawhide] 
name=Fedora Rawhide
mirrorlist=http://fedora.redhat.com/download/mirrors/fedora-core-rawhide
enabled=1
gpgcheck=0
<!-- activate the following line to switch to the other repository's kernels
-->
#exclude=kernel*


file /etc/yum.repos.d/rhpeople-sgrubb.repo :

[sgrubb] 
name=Steve Grubb
baseurl=http://people.redhat.com/sgrubb/files/lspp/
<!-- change the following line to "enabled=1" to activate this repository
-->
enabled=0
gpgcheck=0
exclude=

The exclude=kernel* line ensures that YUM picks kernels from the sgrubb repository only. It's recommended though to use the Rawhide kernel first to verify that everything is working before switching to the LSPP one.

Update The System

Now that you have YUM configured it is time to use it to update your system. First, you need to upgrade the kernel and its dependencies; the plain "yum update" doesn't update the kernel. Then reboot and delete the old kernel, it conflicts with newer packages. Finally, update the rest of the system.

In order to do that run the following commands as root:

yum update kernel
reboot
rpm -qa | grep kernel
rpm -e kernel-2.6.11-1.1369_FC4
yum update

After the update has finished, reboot your system and verify that everything is still working as you expect. This is also the time to fix any problems you may have encountered up to this point. Keep in mind that you are now running a bleeding edge system which will most likely have a number of bugs; if you find any especially nasty bugs you might want to check the Fedora Project's Bug Tracking System, Bugzilla, which you can access here:

as the Bugzilla sometimes has notes on workarounds and fixes.

Once the rawhide system works as expected, you can update to the LSPP bleeding edge kernel to pick up the latest changes that aren't in rawhide yet. To do this, add the setting exclude=kernel* to the /etc/yum.repos.d/fedora-rawhide.repo file, and set enabled=1 in the /etc/yum.repos.d/rhpeople-sgrubb.repo file (cf. previous section).

Install And Configure The MLS Policy

It is finally time to install the MLS policy. You can do this using YUM and the following command:


If you are only interested in the binary MLS policy you can omit the 'selinux-policy-mls-sources' package. However, considering the experimental nature of this policy at the current point in time I would highly recommend you install the MLS policy sources as well to help debug any problems you may encounter.

Once you have the new MLS policy installed you should change the file '/etc/selinux/config' such that the two lines below:

SELINUX=enforcing
SELINUXTYPE=targeted

are now set like this:

SELINUX=permissive
SELINUXTYPE=mls

Now you can run this command:

touch /.autorelabel

You should now reboot your system into single-user mode. The filesystems will be relabeled with the MLS labels on boot automatically.

Once the relabeling is finished you should reboot your system into multi-user mode. you should edit the file '/etc/selinux/config' such that the line:

SELINUX=permissive

reads:

SELINUX=enforcing

and reboot. Once the system reboots you should now have a working Fedora Core system running the MLS policy. However, please keep in mind that your system is now running bleeding edge software and as a result it may experience problems from time to time. It is a good idea to get into the habit on using YUM on a regular basis to get all of the latest fixes.

Initializing the MLS configuration

Defining levels and categories

Edit the file '/etc/selinux/mls/setrans.conf' to create labels and categories; refer to the comments in that file for examples.

Defining users

Note: for more information and examples, please see also James Morris' "Getting started with MCS" guide: http://james-morris.livejournal.com/8228.html

There are three different types of user definitions in the SELinux MLS system: Unix users, SELinux users, and SELinux logins.

The normal Unix user identity is defined in the /etc/passwd file. This part works just like in a non-MLS system.

SELinux users are those mentioned in the policy, these are normally generic classes of users such as user_u and staff_u associated with roles and label ranges. For example, you need to have the staff_r role to be allowed to use su.

SELinux logins map Unix users to SELinux user classes, and define individual labels (clearances) for each user.

SELinux users are stored inside the SELinux policy database. Use semanage user -l to view the currently defined user classes, and semanage user -m to modify properties. You normally won't want to add additional SELinux user classes. The default SELinux user_u definition only allows the "s0" label, you'll probably want to define a more flexible range of labels available for users. The range configured here is an upper bound, you can restrict individual users to a subset of the labels and categories available for the class.

Warning: In current versions, semanage doesn't work in enforcing mode. Try setenforce 0 as a workaround, and don't forget to switch back to setenforce 1 before proceeding with testing.

Warning: If you get "permission denied" errors when logging in due to inaccessible /home directory, try chcon -t usr_t /home as a temporary workaround.

Follow the following procedure to add new users:

newrole -r sysadm_r

setenforce 0

useradd -m jdoe

semanage user -m -r s0-s15:c0.c255 user_u

semanage login -a -s user_u -r s0-s3:c0.c15 jdoe

chcon -l s0-s3:c0.c15 /home/jdoe

setenforce 1

Additional Notes And Troubleshooting

Relabeling '/var/lib/nfs/rpc_pipefs'

Depending on your configuration you may need to run the following commands as root before changing into the MLS enforcing mode in section 2.5:

service rpcidmapd stop
umount /var/lib/nfs/rpc_pipefs
chcon system_u:object_r:var_lib_nfs_t:s0 /var/lib/nfs/rpc_pipefs
mount -t rpc_pipefs sunrpc /var/lib/nfs/rpc_pipefs
service rpcidmapd start

Using YUM/RPM

When using YUM or RPM to change the state of the system you should switch to the 'sysadm_r' role, even when in 'permissive' mode, before doing anything. You can verify your role at any time by running the following command:


You can switch to the 'sysadm_r' role by running the following command when logged in as 'root':


Checking Filesystem Labels

After upgrading the policy or kernel RPMs you should verify that the filesystem is still labeled correctly. You can do this with with the following commands:

touch /.autorelabel
reboot

Alternatively, you can use the command fixfiles check /, but this is considered deprecated.

Use the restorecon command to fix individual file or directory labels, such as after moving files around or restoring a backup copy. For example:


Disabling The 'mDNSResponder' Service

The 'mDNSResponder' service will fill up your audit logs with lots of AVC denials as it tries to talk over UDP. Unless you are running a 'Howl' client you probably do not need this service. You can disable it with the following command:


Viewing audit logs

Due to the MLS levels, you'll get a "permission denied" error when trying to view the audit log as root. This is by design; root logs in with the SystemLow level which doesn't have read access to the SystemHigh audit logs. Use the following command to switch levels:


Note that you now won't be able to write to files such as the bash history that have less restrictive levels.