Gentoo Logo

Disclaimer : This document is not valid and is not maintained anymore.


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


2. Configuring SELinux For Your Needs

Content:

2.a. Administering Users

Introduction

During the installation, we already covered how to map a Linux user to a SELinux user. In the example, we used a hypothetical user "john" and mapped him to the SELinux user "staff_u". If you are running a multi-user system, managing the right mappings is important. A user that is mapped to the SELinux user "user_u" will not get any additional rights. Even if you would give that user additional rights through commands such as sudo, the SELinux policy will not allow this user to do anything that is administration related.

For this reason, it is important to go over the SELinux user mappings and the Linux users on your system.

User Mappings

Run semanage login -l to show the current mappings between Linux logins and SELinux users.

Code Listing 1.1: Running semanage login -l

# semanage login -l

Login Name                SELinux User

__default__               user_u
root                      root
john                      staff_u
system_u                  system_u

The "user_u" SELinux user is for regular accounts. As such, the special __default__ mapping is defined by SELinux to denote every login that is not defined otherwise. This makes sure that a newly defined account does not get elevated privileges by default.

The next table gives an overview of the standard SELinux users available after an installation.

SELinux User Description
user_u Default regular SELinux user, which should be used by end-user accounts that are not going to administer any service(s) on the system
staff_u SELinux user for administrators. This user has the right to switch roles and as such gain elevated privileges
root SELinux user for the root account. It differs little from the staff_u account beyond being a different ID. This ensures that files protected by the user based access control for root cannot be handled by the staff_u (and other) users
sysadm_u SELinux user for system administration. By default, this account is not immediately used as this user immediately gets the administrative role (whereas staff_u and root still need to switch roles).
system_u SELinux user for system services. It should never be used for end users or administrators as it provides direct access to the system role (and privileges)
unconfined_u Used when the policy is targeted, this SELinux user has many privileges (it is essentially not limited in its actions, although it is still handled through SELinux - just through a "wide open" policy).

To map a user to a specific SELinux user, use semanage login -a:

Code Listing 1.2: Mapping a user 'sophie' to the staff_u user

# semanage login -a -s staff_u sophie

However, when you update such mapping, the files in that users' home directory will be owned by a wrong SELinux user. It is therefor important to relabel the files of that user:

Code Listing 1.3: Relabeling sophie's files

# restorecon -R -F /home/sophie

Additional SELinux Accounts

It is perfectly possible to create additional SELinux accounts, and then map the Linux logins to these new accounts. This can be necessary when you want a more thorough auditing (on end user level) or when you will be enhancing the policy with additional roles. Also, if you want to use the User Based Access Control feature, using different SELinux users is important to enforce the control on different users (if they all use the same SELinux user, then UBAC has little to no effect).

Managing the SELinux accounts is done through semanage user:

Code Listing 1.4: Creating a SELinux user

# semanage user -a -R "staff_r sysadm_r" sophie

Let's verify how the SELinux users are currently configured:

Code Listing 1.5: Checking the SELinux user identities

# semanage user -l
SELinux User    SELinux Roles

root            staff_r sysadm_r
sophie          staff_r sysadm_r
staff_u         staff_r sysadm_r
sysadm_u        sysadm_r
system_u        system_r
unconfined_u    unconfined_r
user_u          user_r

# semanage login -l
Login Name                SELinux User

__default__               user_u
root                      root
sophie                    staff_u
swift                     staff_u
system_u                  system_u

Now that a new SELinux user called "sophie" exists, we can now update the Linux user mapping for "sophie" towards the new SELinux user "sophie":

Code Listing 1.6: Updating the Linux user mapping

# semanage login -m -s sophie sophie
# semanage login -l
Login Name                SELinux User

__default__               user_u
root                      root
sophie                    sophie
swift                     staff_u
system_u                  system_u

Again, do not forget to relabel this users' files.

As you can see, managing SELinux users means defining the roles to which the user has access to. We already gave a high-level introduction to the default roles in SELinux Concepts, but as roles are important when using a Mandatory Access Control system, let's refresh our memory again:

SELinux Role Description
user_r Default end-user role. This role provides access to regular applications and activities, but does not allow any system or service administration beyond what is expected for a regular user.
staff_r Default administration role for day-to-day activities. This role has some additional privileges beyond what is offered through user_r, but is not a full system administrative role. It is meant for the non-administrative activities done by operators and administrators
sysadm_r System administration role. This role is highly privileged (since it also contains the privileges to update the policy) and should only be given to fully trusted administrators. It is almost never immediately granted to users (they first need to switch roles) except for direct root access (for instance through the console)
system_r System service role, which is used for the runtime services (processes). It is only granted to users when they get specific, limited administrative rights (for instance administration rights on a single daemon domain).
unconfined_r The unconfined role is used when the targeted policy is supported. This role is given to unconfined users (such as the SELinux unconfined_u user) which have very wide privileges (they almost run without constraints).

It should be noted that these roles are the default ones, but the security administrator - yes, that means you - can create additional roles and add particular privileges to it. We will discuss this later in this book as it means you'll need to update the Gentoo Hardened SELinux policy.

2.b. Reading Audit Logs

Introduction

When working with a SELinux-enabled system, you will eventually notice that things behave differently, but without giving any meaningful error message. Usually, when SELinux "denies" a particular access, it logs it into the audit log of the system, but for the application itself, it is perfectly possible that it just silently dies. If not, you're most likely to get a permission denied error message.

Initially, SELinux is running in permissive mode, which means that SELinux will log what it would deny, but still let it through. This mode is perfect for getting the system in shape without having too much problems keeping it running. Once you think your security settings are in order, then this mode can be switched from permissive to enforcing. We'll talk about these modes later.

First, let's take a look at the audit log and see what it is saying...

Audit Log Location(s)

The SELinux kernel code writes its denials (and sometimes even allowed but audited activities) into the audit log. If you are running on a Gentoo Hardened installation with the syslog-ng system logger, then the logger is already configured to place these audit lines in /var/log/avc.log. However, different system loggers or system logger configurations might put the entries in a different log location (such as /var/log/audit.log).

Below, you'll find the appropriate lines for the syslog-ng system logger configuration for writing the events in /var/log/avc.log.

Code Listing 2.1: syslog-ng.conf excerpt for SELinux AVC entries

# The following lines are only /part/ of the configuration file!
source kernsrc  { file("/proc/kmsg");       };
destination avc { file("/var/log/avc.log"); };
filter f_avc    { message(".*avc: .*");     };

log {
  source(kernsrc);
  filter(f_avc);
  destination(avc);
};

What is AVC?

As we mentioned, SELinux writes its entries in the audit log. These entries are called avc messages or avc log entries. The abbreviation AVC stands for Access Vector Cache and, like the name sais, is a caching system.

Using an access vector cache improves performance on dealing with (and enforcing) activities and privileges. Since SELinux offers a very detailed approach on privileges and permissions, it would become quite painful (performance-wise) if each call means that the SELinux code needs to look up the domain, the target resource label, the privilege and if it is allowed or not over and over again. Instead, SELinux uses the Access Vector Cache to store past requests/responses. It is the AVC subsystem that is responsible for checking accesses and (if necessary) logging it.

Reading an AVC Denial Message

Below you'll find a typical AVC denial message.

Code Listing 2.2: Example AVC denial message

Oct 15 13:04:54 hpl kernel: [963185.177043] type=1400 audit(1318676694.660:2472): 
  avc:  denied  { module_request } for  pid=14561 comm="firefox" kmod="net-pf-10"
  scontext=staff_u:staff_r:mozilla_t tcontext=system_u:system_r:kernel_t tclass=system

Let's analyze each part of this message one by one.

Code Listing 2.3: AVC denial: Timestamp and location information

Oct 15 13:04:54 hpl kernel: [963185.177043] type=1400 audit(1318676694.660:2472): 
  avc:  denied  { module_request } for  pid=14561 comm="firefox" kmod="net-pf-10"
  scontext=staff_u:staff_r:mozilla_t tcontext=system_u:system_r:kernel_t tclass=system

This first part of the message informs you when the message was written (Oct 15 13:04:54), on which host (hpl) and how many seconds since the system was booted (963185.177043).

Code Listing 2.4: AVC denial: source information

Oct 15 13:04:54 hpl kernel: [963185.177043] type=1400 audit(1318676694.660:2472): 
  avc:  denied  { module_request } for  pid=14561 comm="firefox" kmod="net-pf-10"
  scontext=staff_u:staff_r:mozilla_t tcontext=system_u:system_r:kernel_t tclass=system

Next is the source of the denial, i.e. what process is trying to do something. In this case, the process is firefox, with PID 14561, which is running in the source domain staff_u:staff_r:mozilla_t.

Code Listing 2.5: AVC denial: target resource

Oct 15 13:04:54 hpl kernel: [963185.177043] type=1400 audit(1318676694.660:2472): 
  avc:  denied  { module_request } for  pid=14561 comm="firefox" kmod="net-pf-10"
  scontext=staff_u:staff_r:mozilla_t tcontext=system_u:system_r:kernel_t tclass=system

The target of the activity is a kernel module (net-pf-10, which is the internal name given for IPv6), labeled system_u:system_r:kernel_t

Code Listing 2.6: AVC denial: denied action

Oct 15 13:04:54 hpl kernel: [963185.177043] type=1400 audit(1318676694.660:2472): 
  avc:  denied  { module_request } for  pid=14561 comm="firefox" kmod="net-pf-10"
  scontext=staff_u:staff_r:mozilla_t tcontext=system_u:system_r:kernel_t tclass=system

Finally, the action that is denied (module_request) and its class (system). These classes help you to identify what is denied, because a read on a file is different from a read on a directory.

For instance, in the following case, a process gorg with PID 13935 is trying to read a file called localtime with inode 130867 which resides on the device /dev/md3:

Code Listing 2.7: AVC denial example

Oct 15 14:40:30 hpl kernel: [968909.807802] type=1400 audit(1318682430.323:2614):
  avc:  denied  { read } for  pid=13935 comm="gorg" name="localtime" dev=md3 ino=130867
  scontext=staff_u:sysadm_r:gorg_t tcontext=system_u:object_r:locale_t tclass=file

In this case, it might be obvious that the file is /etc/localtime, but when that isn't the case, then you can find the following two commands useful:

Code Listing 2.8: Finding out the target resource based on inode and device

(Find out which device /dev/md3 is)
# mount | grep /dev/md3
/dev/md3 on / type ext4 (rw,seclabel,noatime,barrier=1,nodelalloc,data=journal)

(Find out what file has inode 130867)
# find / -xdev -inum 130867
/etc/localtime

Handling AVC denials

The major part of configuring SELinux is reading the denials, finding out what needs to be fixed (or ignored), fix it, and repeat the steps. Hopefully, the rest of this handbook will help you figure out what is causing a denial.

Denials can be cosmetic (an activity that is denied, but has no effect on the application's functional behaviour). If that is the case, the denial can be marked as dontaudit, meaning that the denial is not logged by default anymore. If you think that a denial is occurring but you do not see it in the logs, try disabling the dontaudit rules:

Code Listing 2.9: Disabling dontaudit

(The command can also be abbreviated to "semodule -DB")
# semodule --build --disable_dontaudit

In most cases though, denials need to be acted upon. Actions that might need to happen are:

  • relabeling the target resource (wrong labels might cause legitimate actions to be denied)
  • relabeling the source (process' binary file) as a wrong label might cause the application to run in the wrong domain
  • loading a necessary SELinux module, since the modules contain the rules to allow (and label) resources. Without the appropriate module loaded, you will notice denials since no other module gives the necessary grants (allow statements)
  • granting the right role to the user executing the application. We have covered users and their roles initially but we will go deeper into this subject later in the handbook.
  • adding your own SELinux policy statements, most likely because no SELinux policy module exists for the application you are trying to run

2.c. Using (File) Labels

Introduction

Within SELinux, access privileges are based on the label given on the originating part (called the domain) and its target resource. For instance, a process running in the passwd_t domain wants to read (= privilege) the file /etc/shadow which is labeled shadow_t (= the target resource). It comes to no surprise then that the majority of SELinux administration is (re)labeling the resources correctly (and ensuring their label stays correct).

Getting File Label(s)

There are many ways to relabel commands, and none of them are equal to another. But before we explain this in more detail, let's first take a look at a few file labels (and how you can query them).

In SELinux, labels are given on a file level through the file systems' ability to keep extended attributes. For SELinux, the attribute is called security.selinux and can be obtained through getfattr:

Code Listing 3.1: Getting a file's extended attribute for SELinux

$ getfattr -n security.selinux /etc/hosts
# file: etc/hosts
security.selinux="system_u:object_r:net_conf_t"

Of course, getting the file attribute this way is time consuming and not that flexible. For this purpose, most important applications (including coreutils) are made SELinux-aware. These applications mostly use the -Z option to display the SELinux context information. In case of files, this means the extended attribute content:

Code Listing 3.2: Getting the context of a file

$ ls -Z /etc/hosts
system_u:object_r:net_conf_t   /etc/hosts

Other commands exist that display the context as it should be, like matchpathcon. However, their purpose is to query the SELinux policy on your system to find out what the policy ought to be, not what it is:

Code Listing 3.3: Difference between context and matchpathcon result

$ ls -Z /etc/portage/make.conf
staff_u:object_r:etc_t    /etc/portage/make.conf
$ matchpathcon /etc/portage/make.conf
/etc/portage/make.conf            system_u:object_r:portage_conf_t

Setting File Label(s)

Now how can you manipulate file labels? Well, first of all: you will not be allowed to change the file labels of any possible file (not even if you are the owner of that file) unless the SELinux policy allows you to. These allow rules are made on two privilege types: which labels are you allowed to change (relabelfrom) and to which labels are you allowed to change (relabelto). You can query these rules through sesearch:

Code Listing 3.4: Querying the relabelto/relabelfrom types

# From which label on files (-c) is user_t (-s) allowed (-A) to relabel from (-p)?
$ sesearch -s user_t -c file -p relabelfrom -A
[...]
allow user_t mozilla_home_t : file { ... relabelfrom relabelto } ;

If you have the permission, then you can use chcon to change the context of a file:

Code Listing 3.5: Changing a file context

$ ls -Z strace.log
staff_u:object_r:user_home_t  strace.log
$ chcon -t mutt_home_t strace.log
$ ls -Z strace.log
staff_u:object_r:mutt_home_t  strace.log

If you do not hold the right privileges, you will get a descriptive error message:

Code Listing 3.6: Trying to change file context

$ chcon -t shadow_t strace.log
chcon: failed to change context of `strace.log' to `staff_u:object_r:shadow_t': Permission denied

Now, if you now think that chcon is all you need, you're wrong. The chcon command does nothing more than what it sais - change context. But when the system relabels files, these changes are gone. Relabeling files is often done to ensure that the file labels are correct (as in: the labels match what the SELinux policy sais they ought to be). The SELinux policy contains, for each policy module, the list of files, directories, sockets, ... and their appropriate file context (label).

We will look at SELinux policy modules later, but below you'll find an excerpt from such a definition, for the mozilla module:

Code Listing 3.7: Excerpt of the mozilla module file contexts

/usr/bin/firefox-bin                            -- gen_context(system_u:object_r:mozilla_exec_t,s0)
/usr/bin/mozilla-[0-9].*                        -- gen_context(system_u:object_r:mozilla_exec_t,s0)
/usr/bin/mozilla-bin-[0-9].*                    -- gen_context(system_u:object_r:mozilla_exec_t,s0)
/usr/lib(64)?/galeon/galeon                     -- gen_context(system_u:object_r:mozilla_exec_t,s0)
/usr/lib(64)?/netscape/.+/communicator/communicator-smotif\.real -- gen_context(system_u:object_r:mozilla_exec_t,s0)
/usr/lib(64)?/netscape/base-4/wrapper           -- gen_context(system_u:object_r:mozilla_exec_t,s0)
/usr/lib/[^/]*firefox[^/]*/plugin-container     -- gen_context(system_u:object_r:mozilla_plugin_exec_t,s0)
/usr/lib64/[^/]*firefox[^/]*/plugin-container   -- gen_context(system_u:object_r:mozilla_plugin_exec_t,s0)

To put the right label on a file, you can use the setfiles or restorecon commands. Since they are both the same command (but with a slightly different way of using) we'll only talk about restorecon for now - more information on the setfiles command can be found in its man page.

When you use restorecon, the application will query the SELinux policy to find out what the right label of the file should be. If it differs, it will change the label to the right setting. That means that you do not need to provide the label for a file in order for the command to work. Also, restorecon supports recursivity, so you do not need to relabel files one by one.

Code Listing 3.8: Using restorecon

$ ls -Z /etc/portage/make.conf
staff_u:object_r:etc_t            /etc/portage/make.conf
$ restorecon /etc/portage/make.conf
$ ls -Z /etc/portage/make.conf
system_u:object_r:portage_conf_t  /etc/portage/make.conf

Finally, Gentoo also provides a useful application: rlpkg. This script relabels the files of a Gentoo package (rlpkg <packagename>) or, given the right arguments, all files on the file system:

Code Listing 3.9: Using rlpkg

# Relabel the files of the firefox-bin package:
# rlpkg firefox

# Relabel all files on the file system:
# rlpkg -a -r

Overriding the SELinux Policy File Labels

You might not always agree with the label that the SELinux policy enforces on the files: you might have your files located elsewhere (a different location for your Portage tree is a nice example) or you need to label them differently in order for other applications to work. To not have to chcon these files over and over again, you can enhance the SELinux policy on your system with additional file context rules. These rules are used when you call restorecon as well and override the rules provided by the SELinux policy.

To add additional file context rules, you need to use the semanage command. This command is used to manage, manipulate and update the local SELinux policy on your system. In this particular case, we will use the semanage fcontext command:

Code Listing 3.10: Using semanage to add a file context rule

# Mark /mnt/gentoo/etc/portage/make.conf as a portage_conf_t type
# semanage fcontext -a -t portage_conf_t /mnt/gentoo/etc/portage/make.conf

# Mark /mnt/gentoo/usr/portage as portage_ebuild_t
# semanage fcontext -a -t portage_ebuild_t "/mnt/gentoo/usr/portage(/.*)?"

As you can see from the example, you can use wildcards. But beware about using wildcards: when a rule holds a wildcard, it has a lower priority than a rule without a wildcard. And the priority on rules with a wildcard is based on how "down" the string the first occurance of a wildcard is. For more information, please check out our FAQ on "How do I know which file context rule is used for a particular file?."

If you want to delete a file context definition, you use semanage fcontext -d:

Code Listing 3.11: Deleting a file context definition

# semanage fcontext -d -t portage_ebuild_t /mnt/gentoo/etc/portage/make.conf

Finally, to view all file context definitions (both user-set and SELinux policy provided), you can use semanage fcontext -l. To only see the locally set, add -C:

Code Listing 3.12: Viewing user-set file context enhancements

# semanage fcontext -C -l
SELinux fcontext                          type             Context
/opt/xxe/bin/.*\.jar                      all files        system_u:object_r:lib_t
/srv/virt/gentoo(/.*)?                    all files        system_u:object_r:qemu_image_t

Customizable types

Labels on files are not that hard to understand, but you might come into some surprises if you do not know that there are also customizable types.

A customizable type is a specific type which is not touched by the SELinux administration tools by default. If you want to relabel a file that currently holds a customizable type, you will need to force this through the commands (such as restorecon -F).

There are not that many customizable types by default. The list of types that SELinux considers as customizable are mentioned in the customizable_types file within the /etc/selinux/*/contexts location:

Code Listing 3.13: Listing the customizable types

# cat /etc/selinux/strict/contexts/customizable_types
mount_loopback_t
public_content_rw_t
public_content_t
swapfile_t
textrel_shlib_t

Such types exist because these types are used for files whose location is known not to be fixed (and as such, the SELinux policy cannot without a doubt know if the label on the files is correct or not). The public_content_t one, which is used for files that are readable by several services (like FTP, web server, ...), might give you a nice example for such a case.

If you look at the restorecon man page, it mentions both customizable types as well as the user section. The latter is for rules that are identified in the SELinux policy as being files for an end user, like the following definitions in the mozilla policy module:

Code Listing 3.14: User section definition within mozilla module

HOME_DIR/\.mozilla(/.*)?      gen_context(system_u:object_r:mozilla_home_t,s0)
HOME_DIR/\.netscape(/.*)?     gen_context(system_u:object_r:mozilla_home_t,s0)
HOME_DIR/\.phoenix(/.*)?      gen_context(system_u:object_r:mozilla_home_t,s0)

Although in the above example, forcing restorecon on the files is probably correct, there are examples where you do not want this. For instance, the firefox policy by default only allows the application to write to directories labeled mozilla_home_t. If you want to download something, this isn't possible (unless you download it into ~/.mozilla). The solution there is to label a directory (say ~/Downloads) as mozilla_home_t.

2.d. SELinux Policy and Booleans

Introduction

We have dealt with users and labels now, but there is still a third aspect that we haven't touched: the SELinux policy itself.

The SELinux policy as offered by Gentoo Hardened is a carefully tuned SELinux policy, based on the reference policy (a distribution-agnostic SELinux policy) with minor changes. Hopefully, you will not need to rewrite the policy to suit it for your needs, but changes are very likely to occur here and there.

Changing the SELinux Policy Behavior: Booleans

A common and user friendly way of tweaking the SELinux policy is through booleans. A SELinux boolean, also known as a conditional, changes how the SELinux policy behaves based on the setting that the user provides. To make this a bit more clear, let's look at a few booleans available:

Code Listing 4.1: Getting SELinux booleans

# getsebool -a | grep ^user
user_direct_mouse --> off
user_dmesg --> off
user_ping --> on
user_rw_noexattrfile --> off
user_tcp_server --> off
user_ttyfile_stat --> off

Although they might not say much on first sight, these booleans alter how the SELinux policy enforces user activity (hence the booleans starting with user_). For instance, user_ping is set to on, so a user is allowed to use ping. If it was set to off, the SELinux policy would not allow a user to execute ping.

Booleans can be toggled on or off using setsebool or togglesebool. With setsebool you need to give the value (on or off) whereas togglesebool switches the value.

Code Listing 4.2: Disallowing the use of ping by users

# setsebool user_ping off

By default, setsebool does not store the boolean values - after a reboot, the old values are used again. To persist such changes, you need to add the -P option:

Code Listing 4.3: Persistedly allow users to run dmesg

# setsebool -P user_dmesg on

Booleans allow administrators to tune the policy, and allow security administrators to write policies that are flexible enough for a more widespread use. In terms of Gentoo flexibility, these booleans might not be used enough (it would be nice to couple these booleans on USE flags, so that a server build with USE="ldap" gets the SELinux policy to use ldap, whereas USE="-ldap" disallows it). But still, the use of booleans is a popular method for making a more flexible SELinux policy.

Managing SELinux Policy Modules

In this last part, we'll cover SELinux policy modules. We mentioned before that the SELinux policy used by Gentoo Hardened is based on the reference policy, which offers a modular approach to SELinux policies. There is one base policy, which is mandatory on every system and is kept as small as possible. The rest are SELinux policy modules, usually providing the declarations, rules and file contexts for a single application (or type of applications).

With semodule -l you can see the list of SELinux policy modules loaded:

Code Listing 4.4: Listing the loaded SELinux modules

# semodule -l
alsa       1.11.0
apache     2.3.0
entropyd   1.6.0
dbus       1.15.0
dnsmasq    1.9.0
(...)

Within Gentoo Hardened, each module is provided by the package sec-policy/selinux-<modulename>. For instance, the first module encountered in the above example is provided by selinux-alsa:

Code Listing 4.5: The SELinux policy module package in Gentoo

$ emerge --search selinux-alsa
Searching...
[ Results for search key : selinux-alsa ]
[ Applications found : 1]

* sec-policy/selinux-alsa
    Latest version available: 2.20110726
    Latest version installed: 2.20110726
    Size of files: 574 kB
    Homepage:      http://www.gentoo.org/proj/en/hardened/selinux/
    Description:   SELinux policy for alsa
    License:       GPL-2

If you need a module that isn't installed on your system, this is considered a bug (packages that need it should depend on the SELinux policy package if the selinux USE flag is set). But once you install the package yourself, the module will be loaded automatically:

Code Listing 4.6: Installing a SELinux policy package

# emerge selinux-screen

If you want to remove a module from your system though, uninstalling the package will not suffice: the SELinux policy module itself is copied to the policy store earlier (as part of the installation process) and is not removed from this store by Portage. Instead, you will need to remove the module manually:

Code Listing 4.7: Uninstalling a SELinux policy module

# emerge -C selinux-screen
# semodule -r screen

2.e. Next steps

What to do now?

Up until now, your system has been running in permissive mode. You will need to enable enforcing before you are properly protected by SELinux. We will discuss how to switch to enforcing mode in Permissive, Unconfined, Disabled or What Not... but before that, you will need to consider a few things...

Initramfs users

If your system uses an initramfs to boot up, you will not be able to boot straight into enforcing mode (due to bug #397597). To work around this issue, you can create the following init script which will switch from a permissive mode into forcing mode reasonably fast within the boot process (and before the network is started):

Code Listing 5.1: Content of /etc/init.d/selinux_enforce

#!/sbin/runscript
# Copyright 1999-2012 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/hardened/selinux/hb-using-configuring.xml,v 1.7 2013/08/10 17:11:03 swift Exp $

description="Switch into SELinux enforcing mode"

depend() {
	need sysfs
}

start() {
	if get_bootparam "norestorecon" ; then
		ewarn "Skipping restoring file contexts in /dev as requested"
	else
		ebegin "Restoring file contexts in /dev"
			restorecon -R /dev
		eend 0
	fi
	
	if get_bootparam "nosetenforce" ; then
		ewarn "Skipping switching to enforcing mode as requested by kernel cmdline"
	else
		. /etc/selinux/config
		CURRENTMODE=$(cat /sys/fs/selinux/enforce)

		if [ "${SELINUX}" = "enforcing" ] && [ "${CURRENTMODE}" = "0" ];
		then
			ebegin "Switching to enforcing mode"
			echo 1 > /sys/fs/selinux/enforce
			eend $?
		else
			ewarn "Not switching to enforcing mode, or enforcing mode already enabled"
		fi
	fi
}

Add the init script to the boot runlevel, and edit your boot loader configuration to always boot with enforcing=0 set. The init script will update the file contexts in /dev and then, if your system is configured to run in enforcing mode, switch to enforcing mode.

If you need to temporarily stay in permissive mode, you can add nosetenforce as boot parameter (after enforcing=0) which will skip the setenforce step).

Users of a graphical environment

If you boot into a graphical environment (using GDM, KDM or another graphical login manager) you will need to update the PAM configuration file(s) of the managers with the following:

Code Listing 5.2: Example update on LXDM PAM configuration file

# /etc/pam.d/lxdm
# [...]
session    required     pam_loginuid.so
session    optional     pam_gnome_keyring.so auto_start
session	   optional     pam_selinux.so

This will ensure that the security context in which you are logged on is set correctly. We will update the packages that place those PAM files accordingly, but it might take some time.


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


Print

View all

Page updated August 10, 2013

Summary: With SELinux now "installed" and enabled (although in permissive mode), we now configure it to suit your particular needs. After all, SELinux is a Mandatory Access Control system where you, as security administrator, define what is allowed and what not.

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.