SELinux/FedoraMLSHowto

From FedoraProject

< SELinux(Difference between revisions)
Jump to: navigation, search
m (1 revision(s))
m (Defining users)
(One intermediate revision by one user not shown)
Line 1: Line 1:
Configuring Fedora Core To Use The MLS SELinux Policy
+
Configuring Fedora To Use The MLS SELinux Policy
  
  
Line 5: Line 5:
  
 
This document is a quick walk-through of how to install the experimental
 
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
+
Multi-Level Security (MLS) policy on a Fedora based system.  The audience
is expected to be familiar with Linux, Fedora Core and to some extent SELinux.
+
is expected to be familiar with Linux, Fedora and SELinux.
  
 
=== Warnings ===
 
=== Warnings ===
  
 
It is recommended that you read the entire document first before starting to
 
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
+
install the system; special attention should be paid to "Additional
Notes And Troubleshooting".  Also, please keep in mind that as part of the
+
Notes And Troubleshooting".
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 ==
 
== Installation Guide ==
  
=== Install Fedora Core ===
+
=== Install Fedora ===
  
The first step is to get a working install of Fedora Core.  This document was
+
The first step is to get a working install of Fedora.  This document was
written using Fedora Core 4 as the base.  The steps required to get the MLS
+
written using Fedora 10 as the base.  The steps required to get the MLS
policy working on different versions of Fedora Core may be different.
+
policy working on different versions of Fedora may be different.
  
The latest version of Fedora Core can be downloaded here:
+
The latest version of Fedora can be downloaded here:
  
* http://fedora.redhat.com
+
* http://fedoraproject.org
 
+
=== 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:
+
 
+
<pre>
+
http_proxy="<proxy URL, i.e. http://my.proxy.com:8080>"
+
HTTP_PROXY="$http_proxy"
+
export http_proxy HTTP_PROXY
+
</pre>
+
 
+
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'' :
+
 
+
<pre>
+
[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*
+
</pre>
+
 
+
 
+
file ''/etc/yum.repos.d/rhpeople-sgrubb.repo'' :
+
 
+
<pre>
+
[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=
+
</pre>
+
 
+
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 ===
 
=== Update The System ===
  
Now that you have YUM configured it is time to use it to update your system.
+
Next, ensure that the system is up-to-date.
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:
 
In order to do that run the following commands as root:
  
 
<pre>
 
<pre>
yum update kernel
+
yum update
 
reboot
 
reboot
rpm -qa | grep kernel
 
rpm -e kernel-2.6.11-1.1369_FC4
 
yum update
 
 
</pre>
 
</pre>
  
 
After the update has finished, reboot your system and verify that everything is
 
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
 
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
+
have encountered up to this point.  If you find any bugs you might want to check
bleeding edge system which will most likely have a number of bugs; if you find
+
the Fedora Project's Bug Tracking System, Bugzilla, which you can access here:
any especially nasty bugs you might want to check the Fedora Project's Bug
+
Tracking System, Bugzilla, which you can access here:
+
  
 
* https://bugzilla.redhat.com/bugzilla
 
* https://bugzilla.redhat.com/bugzilla
  
 
as the Bugzilla sometimes has notes on workarounds and fixes.
 
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 ===
 
=== Install And Configure The MLS Policy ===
Line 129: Line 50:
 
It is finally time to install the MLS policy.  You can do this using YUM and
 
It is finally time to install the MLS policy.  You can do this using YUM and
 
the following command:
 
the following command:
 +
 +
<pre>
 +
yum install selinux-policy-mls
 +
</pre>
  
  
If you are only interested in the binary MLS policy you can omit the
+
Note that this will install mcstrans as a dependency.
'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
 
Once you have the new MLS policy installed you should change the file
Line 152: Line 73:
 
</pre>
 
</pre>
  
Now you can run this command:
+
Now run this command to ensure that files are relabeled with the correct MLS SELinux contexts:
  
 +
<pre>
 
touch /.autorelabel
 
touch /.autorelabel
 +
</pre>
  
 
You should now reboot your system into single-user mode.
 
You should now reboot your system into single-user mode.
 
The filesystems will be relabeled with the MLS labels on boot automatically.
 
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.
+
Once the relabeling is finished you should reboot your system into run-level
you should edit the file '/etc/selinux/config' such that the line:
+
 
 +
Configure the system to boot into run level 3 by default:
 +
 
 +
<pre>
 +
perl -p -i -e "s/^id:5:initdefault:/id:3:initdefault:/g" /etc/inittab
 +
</pre>
 +
 
 +
Now edit the file '/etc/selinux/config' such that the line:
  
 
SELINUX=permissive
 
SELINUX=permissive
Line 168: Line 98:
 
SELINUX=enforcing
 
SELINUX=enforcing
  
and reboot.  Once the system reboots you should now have a working Fedora Core
+
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
 
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
+
is now running a restrictive security policy and as a result it may cause
problems from time to time.  It is a good idea to get into the habit on using
+
unexpected problems.
YUM on a regular basis to get all of the latest fixes.
+
  
 
== Initializing the MLS configuration ==
 
== Initializing the MLS configuration ==
Line 183: Line 112:
  
 
Note: for more information and examples, please see also James Morris' "Getting started with MCS" guide: http://james-morris.livejournal.com/8228.html
 
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.
 
There are three different types of user definitions in the SELinux MLS system: Unix users, SELinux users, and SELinux logins.
Line 201: Line 132:
  
 
<pre>
 
<pre>
 +
 
newrole -r sysadm_r
 
newrole -r sysadm_r
  
 
setenforce 0
 
setenforce 0
  
useradd -m jdoe
+
useradd -d /home/jdoe -m -Z user_u jdoe
  
 
semanage user -m -r s0-s15:c0.c255 user_u
 
semanage user -m -r s0-s15:c0.c255 user_u
  
semanage login -a -s user_u -r s0-s3:c0.c15 jdoe
+
semanage login -m -s user_u -r s0-s3:c0.c15 jdoe
  
 
chcon -l s0-s3:c0.c15 /home/jdoe
 
chcon -l s0-s3:c0.c15 /home/jdoe
Line 231: Line 163:
 
</pre>
 
</pre>
  
=== Using YUM/RPM ===
+
=== Switching Roles ===
  
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 verify your role at any time by running the following command:
 +
 +
<pre>
 +
id -Z
 +
</pre>
 +
 +
You can view the roles available on your system by running the following
 +
command:
 +
 +
<pre>
 +
semanage user -l
 +
</pre>
  
  
 
You can switch to the 'sysadm_r' role by running the following command when
 
You can switch to the 'sysadm_r' role by running the following command when
 
logged in as 'root':
 
logged in as 'root':
 +
<pre>
 +
newrole -r sysadm_r
 +
</pre>
  
  
Line 268: Line 212:
  
 
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:
 
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:
 +
 +
<pre>
 +
newrole -r sysadm_r -l SystemHigh
 +
</pre>
  
  
 
Note that you now won't be able to write to files such as the bash history that have less restrictive levels.
 
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.
 +
 +
<pre>
 +
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
 +
</pre>

Revision as of 14:46, 12 April 2011

Configuring Fedora To Use The MLS SELinux Policy


Contents

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

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

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