fp-wiki>ImportUser (Imported from MoinMoin) |
m (1 revision(s)) |
(No difference)
| |
Revision as of 16:27, 24 May 2008
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.