Gentoo Logo

[ << ] [ < ] [ Home ] [ > ] [ >> ]


7. Change History

Content:

7.a. Introduction

About this document

This document will give an overview of all SELinux documented changes made on particular dates and that might be important for users to follow up through.

Changes that only affect ~arch users will be documented below and moved up when they are stabilized. It is possible though that these changes will be "fixed" automatically and as such removed from this page.

7.b. Overview of Changes for Stable Users

2013/04/19 - Introducing selocal command

With policycoreutils-2.1.13-r11 onwards, a new command called selocal is available. This command allows users to easily add in additional SELinux policy rules to the local policy without having go through the hassle of building and maintaining their own .te files. Instead, this command does that for you.

Rules that are added to the local policy (hence the name, selocal) can be accompanied with a small comment to allow users to describe why a change was added (or to refer to a bug id on Gentoo's bugzilla).

Code Listing 2.1: Adding a rule to the local policy

# selocal -a "rpcbind_stream_connect(sysadm_t)" -c "Be able to call exportfs (NFS)"
# selocal --build --load

With --list you can view the currently added local policy rules, and with --delete they can be removed from the local policy. When you want to have the changes take effect, run selocal --build --load to build the new local policy and load it in memory.

2013/04/16 - Introduce selinux_gentoo init script

With policycoreutils-2.1.13-r8 and later, we now provide our own init script selinux_gentoo, which includes the necessary support for the initramfs users, but also resets the contexts of dynamically generated resources (on pseudo file systems) which are different from the default setting.

The first user here is /sys/devices/system/cpu/online which gets labeled cpu_online_t (from revision 13 of the SELinux policy, or when using live ebuilds for the policy).

The init script will by default also restore the contexts of all /dev devices (unless you boot with the norestorecon option) and will switch to enforcing mode if /etc/selinux/config has SELINUX=enforcing set but the user booted with enforcing=0 (unless you boot with nosetenforce option).

This means that users are now encouraged to add this init script to the boot runlevel:

Code Listing 2.2: Adding selinux_gentoo to the boot runlevel

# rc-update add selinux_gentoo boot

2012/12/04 - Introduce USE=unconfined

From selinux-base-2.20120725-r9 onwards, we will now also support a USE=unconfined setting. When enabled, it will configure your SELinux policy to support the unconfined domains. If your policy is targeted, this behavior will be implied, whereas the strict policy will not consider this USE flag at all (it will not activate unconfined domains on strict).

Supporting this USE flag allows us to differentiate unconfined domains versus regular ones when using the mls or mcs policy types. When set, the selinux-unconfined package will be built as well, and the module will be loaded, and the policy seusers file (which contains the default domain mappings for users) will be updated to use the unconfined_u SELinux user for root and other users.

2012/08/16 - Adding system_r role to admins

Since selinux-base-2.20120725-r3 and later, init scripts will now support the upstream "labeled" init script approach. This means that those services whose init script follows the <domain>_initrc_exec_t naming convention can now be assigned to specific users (allowing those to manage the services without the need to grant them system administration rights).

The downside of this approach is that the system administrator itself (who uses the sysadm_t domain) now also needs to be granted the right to manage those services. And granting this right means that the SELinux user (be it root or staff_u) needs to be granted the system_r role:

Code Listing 2.3: Granting system_r role

# semanage user -m -R "staff_r sysadm_r system_r" root
# semanage user -m -R "staff_r sysadm_r system_r" staff_u

2012/06/24 - Definition of /run in fstab

The /run location needs to be mounted with the var_run_t context. To do so, /etc/fstab needs to be modified as per the instructions in Setting the filesystem contexts.

2012/05/26 - Support of initramfs

Users who boot with an initramfs will need to boot in permissive mode first, and later on switch to enforcing mode. This can be done automatically using an init script, as documented at Initramfs users.

2012/05/26 - Support for graphical login managers

Users who boot into a graphical environment (such as through GDM) will need to edit their PAM configuration files accordingly to support SELinux security context settings. This is documented at Users of a graphical environment.

2012/05/18 - No more sandbox configuration needed

The previously documented editing of /etc/sandbox.conf to open write access to /sys/fs/selinux/context can be removed as the SELinux profile does this now automatically.

2012/04/29 - Edit of lvm-start/stop scripts no longer needed

When users install the newly stabilized 2.20120215 policies, the documented editing of /lib/rcscripts/addons/lvm-st*.sh is no longer needed.

2012/02/21 - /dev mount line in fstab no longer needed

The previously documented /dev mount line in /etc/fstab is no longer needed as util-linux-2.20.1-r1 has been marked stable (which contains the correct bug fix).

2011/12/10 - Deprecation of selinux/v2refpolicy/* profiles

The old SELinux profiles (starting with selinux/v2refpolicy) are not supported anymore. Users are strongly encouraged to switch to the new profiles (those ending with /selinux).

2011/07/22 - Introduction of MLS/MCS support

We now support MLS and MCS, right next to targeted and strict SELinux policy types. When using MLS or MCS, you will need to update the /tmp entry in your /etc/fstab to use rootcontext=system_u:object_r:tmp_t:s0 (note the trailing :s0).

7.c. Overview of Changes for ~Arch Users

2013/07/07 - Introduced support for mcstrans

When the SELinux policy is MLS-enabled (so it is MCS or MLS), then we have the option of managing categories. Categories allow us to "tag" resources and make sure that only processes that have the right category set assigned to them can read/manipulate the resources.

For SELinux, categories are numbers, starting from c0 (category zero) to whatever maximum is used in the policy:

Code Listing 3.1: Checking the maximum number of categories

$ seinfo | grep Categories
  Sensitivities:      1   Categories:       1024

For most administrators/humans though, this is not that efficient. To support more human readable formats, SELinux supports category translations (and even sensitivity translations). Inside a configuration file (setrans.conf in the main configuration directory, like /etc/selinux/mcs) administrators can enter common sensitivity sets and ranges. The chcat tool can then be used to list those:

Code Listing 3.2: Listing translated sensitivity ranges

# chcat -L
s0                             SystemLow
s0-s0:c0.c1023                 SystemLow-SystemHigh
s0:c0.c1023                    SystemHigh

To enable these translations, create the proper translation file (of which you can find numerous examples in /usr/share/doc/policycoreutils-*/mcstrans) and then start the mcstransd service.

Code Listing 3.3: Starting the mcstransd service

# rc-service mcstransd start

That's it - if we now look at contexts, we will see the translated ranges:

Code Listing 3.4: Listing contexts to see translated ranges

# ls -lZ seusers
-rw-r--r--. root root system_u:object_r:selinux_config_t:SystemLow seusers

[ << ] [ < ] [ Home ] [ > ] [ >> ]


Print

View all

Page updated August 16, 2013

Summary: As documentation evolves with the technology, this handbook too sees its fair share of changes. To allow users, who are already on SELinux, to verify if there are any changes they need to be aware off, this chapter lists the changes in chronological order.

Chris PeBenito
Author

Sven Vermeulen
Author

Chris Richards
Author

Donate to support our development efforts.

Copyright 2001-2014 Gentoo Foundation, Inc. Questions, Comments? Contact us.