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:
Update The System
Next, ensure that the system is up-to-date.
In order to do that run the following commands as root:
yum update reboot
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:
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 YUM and the following command:
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
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
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