SELinux/FedoraMLSHowto

This wiki page is outdated
Please update this wiki page to reflect recent events or newly available information.

Configuring Fedora 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 based system. The audience is expected to be familiar with Linux, Fedora and SELinux.

Warnings

It is recommended that you read the entire document first before starting to install the system; special attention should be paid to "Additional Notes And Troubleshooting".

Installation Guide

Install Fedora

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

The latest version of Fedora can be downloaded here:

• http://fedoraproject.org

Update The System

Next, ensure that the system is up-to-date.

In order to do that run the following commands as root. For Fedora 22 and later versions use DNF:

dnf upgrade

For Fedora 21 and earlier versions use YUM:

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. If you find any bugs you might want to check the Fedora Project's Bug Tracking System, Bugzilla, which you can access here:

• https://bugzilla.redhat.com/bugzilla

as the Bugzilla sometimes has notes on workarounds and fixes.

Install And Configure The MLS Policy

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

dnf install selinux-policy-mls

Or:

yum install selinux-policy-mls

Note that this will install mcstrans as a dependency.

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 run this command to ensure that files are relabeled with the correct MLS SELinux contexts:

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 run-level

inittab is no longer used when using systemd
systemd uses targets instead of runlevels. By default, multi-user.target corresponds to runlevel3, while graphical.target corresponds to runlevel5.

Configure the system to boot into run level 3 by default:

perl -p -i -e "s/^id:5:initdefault:/id:3:initdefault:/g" /etc/inittab

On systems with systemd

ln -sf /lib/systemd/system/multi-user.target /etc/systemd/system/default.target

Now 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 system running the MLS policy. However, please keep in mind that your system is now running a restrictive security policy and as a result it may cause unexpected problems.

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

For a gentle introduction to Multilevel Security under Selinux, please see also James Morris "An Overview of Multilevel Security and LSPP under Linux" http://james-morris.livejournal.com/5020.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 -d /home/jdoe -m -Z user_u jdoe

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

semanage login -m -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

Switching Roles

You can verify your role at any time by running the following command:

id -Z

You can view the roles available on your system by running the following command:

semanage user -l

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

newrole -r sysadm_r

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:

newrole -r sysadm_r -l SystemHigh

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

LSPP

Build and run the latest LSPP rpm.

git clone http://klaus.vh.swiftco.net/lspp/git/
cd git/
mkdir Output/
./make-rpm 0.65 1
rpm -Uvh Output/RPMS/noarch/lspp-eal4-config-ibm-0.65-1.fc10.noarch.rpm
/usr/sbin/capp-lspp-config