SELinux/FAQ

Introduction
Using SELinux requires administrators a more thorough knowledge of their system and a good idea on how processes should behave. Next to the SELinux resources, a proper FAQ allows us to inform and help users in their day-to-day SELinux experience.

The FAQ is an aggregation of solutions found on IRC, mailinglists, forums and elsewhere. It focuses on SELinux integration on Gentoo Hardened, but general SELinux questions that are popping up regularly will be incorporated as well.

Does SELinux enforce resource limits?
No, resource limits are outside the scope of an access control system. If you are looking for this type of support, take a look at technologies like grsecurity, cgroups, pam and the like.

Can I use SELinux with grsecurity (and PaX)?
Definitely, we even recommend it. However, it is suggested that grsecurity's ACL support is not used together with SELinux as it would be redundant to SELinux's access control. Choose one or the other.

Can I use SELinux and the hardened compiler (with PIE-SSP)?
Definitely. We also suggest to use PaX to take full advantage of the PIE features of the compiler.

Can I use SELinux and RSBAC?
Yes, SELinux and RSBAC can be used together, but it is not recommended. Both frameworks (RSBAC and the SELinux implementation on top of Linux' Linux Security Modules framework) have a slight impact on system performance. Enabling them both only hinders performance more, for little added value since they both offer similar functionality.

In most cases, it makes more sense to use RSBAC without SELinux, or SELinux without RSBAC.

Can I use SELinux with any file system?
SELinux requires access to a file's security context to operate properly. To do so, SELinux uses extended file attributes which needs to be properly supported by the underlying file system. If the file system supports extended file attributes and you have configured your kernel to enable this support, then SELinux will work on those file systems.

General Linux file systems, such as ext2, ext3, ext4, jfs, xfs and btrfs support extended attributes (but don't forget to enable it in the kernel configuration) as well as tmpfs (for instance used by udev). If your file system collection is limited to this set, then you should have no issues.

Ancillary file systems such as vfat and iso9660 are supported too, but with an important caveat: all files in each file system will have the same SELinux security context information since these file systems do not support extended file attributes.

Network file systems can be supported in the same manner as ancillary file systems (all files share the same security context). However, some development has been made in supported extended file attributes on the more popular file systems such as NFS. Although this is far from production-ready, it does look like we will eventually support these file systems on SELinux fully as well.

Can I use SELinux with AMD64 no-multilib?
Yes, just use the profile and you're all set.

What is UBAC exactly?
UBAC, or User Based Access Control, introduces additional constraints when using SELinux policy. Participating domains / types that are both marked as a ubac_constrained_type (which is an attribute) will only have the allowed privileges in effect if they both run with the same SELinux user context.

Of course, this is not always the case. Besides the earlier mentioned requirement that both types are ubac_constrained_type, if the source domain is sysadm_t, then the constraint will not be in effect (the sysadm_t domain is exempt from UBAC constraints). Also, if the source or destination SELinux user is system_u then the constraint will also not be in effect.

How do I enable SELinux?
This is explained in the SELinux installation instructions.

How do I switch between permissive and enforcing?
The easiest way is to use the setenforce command. With setenforce 0 SELinux is told to run in permissive mode. Similarly, with setenforce 1 SELinux is told to run in enforcing mode.

It is also possible to add a kernel option  or   in the bootloader configuration (or during the startup routine of the system). This allows users to run SELinux in permissive or enforcing mode from the start of the system.

The default state of the system is kept in.

How do I disable SELinux completely?
It might be possible that running SELinux in permissive mode is not sufficient to properly fix any issue you have. To disable SELinux completely, you need to edit and set. Next, reboot the system.

How do I know which file context rule is used for a particular file?
If you use the matchpathcon command, it will tell you what the security context for the given path (file or directory) should be, but it doesn't tell you which rule it used to deduce this. To do that, you can use findcon :

When the SELinux utilities try to apply a context, they try to match the rule that is the most specific, so in the above case, it is the one that leads to the initrc_state_t context.

The most specific means, in order of tests:


 * 1) If line A has a regular expression, and line B doesn't, then line B is more specific.
 * 2) If the number of characters before the first regular expression in line A is less than the number of characters before the first regular expression in line B, then line B is more specific
 * 3) If the number of characters in line A is less than in line B, then line B is more specific
 * 4) If line A does not map to a specific SELinux type, and line B does, then line B is more specific

If there are specifications that match inside both the policy-provided contexts, the homedir generated contexts and locally-defined contexts, then the following precedence rules apply:


 * 1) Rules (regardless of their origin) that do not have any regular expressions take precedence over any other expressions
 * 2) Expressions inside the locally-defined contexts  as generated by semanage fcontext</tt> commands take precedence over the homedirs- and policy-provided ones
 * 3) Expressions inside the homedirs generated contexts  take precedence over the policy-provided ones

How do I make small changes (additions) to the policy?
If you are interested in the Gentoo Hardened SELinux development itself, please have a look at the SELinux development resources.

However, you will eventually need to keep some changes on your policy, due to how you have configured your system or when you need to allow something that is not going to be accepted as a distribution-wide policy change. In that case, read on.

Updates on the policy are only possible as long as you need to allow additional privileges. It is not possible to easily remove rules from the policy, only enhance it. To maintain your own set of additional rules, create a file in which you will keep your changes. In the next example, I will use the term, substitute with whatever name you like - but keep it consistent. In the file put in the following text (again, substitute  with your chosen name):

In this file, you can add rules as you like. In the next example, we add three rules:


 * 1) Allow mozilla_t</tt> the execmem</tt> privilege (based on a denial that occurs when mozilla fails to start)
 * 2) Allow ssh_t</tt> to connect to any port rather than just the SSH port
 * 3) Allows the user_t</tt> domain to send messages directly to the system logger

If you need to provide raw allow statements (like the one above for the mozilla_t</tt> domain), make sure that the type (mozilla_t</tt>), class (process</tt>) and privilege (execmem</tt>) are mentioned in the  paragraph.

When using interface names, make sure that the types (ssh_t</tt> and user_t</tt>) are mentioned in the  paragraph.

To find the proper interface name (like corenet_tcp_connect_all_ports</tt> above), you can either look for it in the SELinux Reference Policy API online or, if is built with the doc</tt> USE flag, in. Of course, you can also ask for help in #gentoo-hardened on irc.freenode.net, the mailinglist, forums, etc. to find the proper rules and statements for your case.

With the policy file created, you can then build it using the provided by the system:

Then, if the builds succeeds, you can load it in memory. Once loaded, it will be loaded after every boot as well, so you do not need to repeat this over and over again.

How to I load an entire policy set?
Usually, it is sufficient to go into the location and execute semodule</tt> like so:

With the 2.4 userspace, that command can be simplified:

However, there is a downside. With the 2.4 userspace onwards, modules can have a certain priority. Modules that were loaded in through the 2.3 userspace utilities are at priority 100, whereas new modules are at priority 400. When a new set of policy modules is loaded, but it does not contain every previous module, then weird things can happen.

Consider the following situation where there no longer is a storage</tt> module:

However removing that module is not possible, because the currently loaded modules depend on objects defined by it:

As it is not possible to load in a set of new policies on a new priority (400) and remove an older one from another priority (100) we seem to be in a deadlock.

To resolve this, make an empty policy module named storage</tt> and load it (at the higher priority):

With that in place, there is now an empty <tt>storage</tt> module active at priority 400, allowing the administrator to remove the older one, followed by the empty one.

I get a register_security error message when booting
During boot-up, the following message pops up:

This is nothing to worry about (and perfectly normal).

This means that the Capability LSM module couldn't register as the primary module, since SELinux is the primary module. The third message means that it registers with SELinux as a secondary module.

I get a 'Permission ... in class ... not defined' message during booting
During boot-up, the following message is shown:

This means that the Linux kernel that you are booting supports permissions that are not defined in the policy (as offered through the package). If you do not notice any errors during regular operations, then this can be ignored (the permissions will be made part of upcoming policy definitions).

I get a missing SELinux module error when using emerge
When trying to use <tt>emerge</tt>, the following error message is displayed:

This indicates that the portage SELinux module is missing or damaged. Recent Portage versions provide this module out-of-the-box, but the security contexts of the necessary files might be wrong on your system. Try relabeling the files of the portage package:

I get 'FEATURES variable contains unknown value(s): loadpolicy'
When running emerge, the following error is shown:

This is a remnant of the older SELinux policy module set where policy packages might require this FEATURE to be available. This has however since long been removed from the tree.

Please update your profile to a recent SELinux profile (one ending with ) and make sure that does not have   set.

During rlpkg I get 'conflicting specifications for ... and ..., using ...'
When trying to relabel a package ( rlpkg packagename ) or system ( rlpkg -a -r ) you get a message similar to the following:

This is most likely caused by hard linked files. Remember, SELinux uses the extended attributes in the file system to store the security context of a file. If two separate paths point to the same file using hard links (i.e. the files share the same inode) then both files will have the same security context.

The solution depends on the particular case; in order of most likely to happen and resolve:

It is also not a bad idea to report (after verifying if it hasn't been reported first) this on Gentoo's bugzilla so that the default policies are updated accordingly.
 * 1) Although both files are the same, they are not used in the same context. In such cases, it is recommended to remove one of the files and then copy the other file back to the first ( rm B; cp A B ). This way, both files have different inodes and can be labeled accordingly.
 * 2) Both files are used for the same purpose; in this case, it might be better to label the file which would not be labeled correctly (say a binary somewhere in a  location) using <tt>semanage</tt> ( semanage fcontext -a -t correct_domain_t /usr/lib64/path/to/file )

During package installation, ld.so complains 'object 'libsandbox.so' from LD_PRELOAD cannot be preloaded: ignored'
During installation of a package, you might see the following error message:

This message should only occur after the Setting SELinux security labels message. It happens because SELinux tells glibc to disable  (and other environment variables that are considered potentially harmful) during domain transitions. Here, portage calls the <tt>setfiles</tt> command (part of a SELinux installation) and as such transitions from <tt>portage_t</tt> to <tt>setfiles_t</tt>, which clears the environment variable.

We believe that it is safer to trust the SELinux policy here (as setfiles runs in its own confined domain anyhow) rather than updating the policy to allow transitioning between <tt>portage_t</tt> to <tt>setfiles_t</tt> without clearing these environment variables. Note that libsandbox.so is not disabled during builds and merges, only during the activity where Portage labels the files it just merged.

So the error is in our opinion cosmetic and can be ignored (but sadly not hidden).

Emerge does not work, giving 'Permission denied: /etc/make.conf'
This is to be expected if you are not using the <tt>sysadm_r</tt> role. Any Portage related activity requires that you are in the <tt>sysadm_r</tt> role. To transition to the role, first validate if you are currently known as <tt>staff_u</tt> (or, if you added your own SELinux identities, a user that has the permission to transition to the <tt>sysadm_r</tt> role). Then run newrole -r sysadm_r to transition.

This is also necessary if you logged on to your system as root but through SSH. The default behavior is that SSH sets the lowest role for the particular user when logged on. And you shouldn't allow remote root logins anyhow.

Cron fails to load in root's crontab with message '(root) ENTRYPOINT FAILED (crontabs/root)'
When you hit the mentioned error with a root crontab or an administrative users' crontab, but not with a regular users' crontab, then check the context of the crontab file:

Next, check what the default context is for the given user (in this case, root) when originating from the <tt>crond_t</tt> domain:

As you can see, the default context is always for the <tt>root</tt> SELinux user. However, the file context in the above example is for the SELinux user <tt>staff_u</tt>. Hence, cron will not be able to read this file (the <tt>user_cron_spool_t</tt> type is a UBAC constrained one).

To fix this, change the user of the file to root:

Another workaround would be to disable UBAC completely. This is accomplished with.

When querying the policy, I get 'ERROR: could not find datum for type ...'
When using <tt>seinfo</tt> or <tt>sesearch</tt> to query the policy on the system, you get errors similar to:

This is most likely because your tools are using a newer binary policy to enforce policy, but an older binary for querying. You can verify if this is the case by listing the last modification time on the files:

The file modified last should be the same one as returned by checking :

If this is not the case (which is very likely since you are reading this FAQ entry) then try forcing the utilities policy version to the correct version:

Portage fails to label files because "setfiles" does not work anymore
Portage uses the <tt>setfiles</tt> command to set the labels of the files it installs. However, that command is a dynamically linked executable, so any update in its depending libraries (,, and of course ) might cause for the application to fail. Gentoo's standard solution (<tt>revdep-rebuild</tt>) will not work, since the tool will try to rebuild, which will fail to install because Portage cannot set the file labels.

The solution is to rebuild while disabling Portage's SELinux support, then label the installed files manually using <tt>chcon</tt>, based on the feedback received from <tt>matchpathcon</tt>.

Now Portage will function properly again, labeling files as they should.

Applications do not transition on a nosuid-mounted partition
If you have file systems mounted with the <tt>nosuid</tt> option, then applications started from these file systems will not transition into their appropriate domain. This is intentional.

So, a <tt>passwd</tt> binary, although correctly labeled <tt>passwd_exec_t</tt>, will not transition into the <tt>passwd_t</tt> domain if the binary is stored on a file system mounted with <tt>nosuid</tt>.

Why do I always need to re-authenticate when operating init scripts?
When you, as an administrator, wants to launch or stop daemons, these activities need to be done as <tt>system_u:system_r</tt>. Switching to this context set is a highly privileged operation (since you are effectively leaving the user context and entering a system context) and hence the default setup requires the user to re-authenticate.

You can ask not to re-authenticate if you use PAM by editing and adding the following line on top:

With this in place, you can now prepend your init script activities with run_init and it will not ask for your password anymore:

How do I use SELinux with initramfs?
We currently do not support booting in enforcing mode with an initramfs image (but we are working on it). For the time being, boot in permissive mode. Once booted, switch to enforcing mode ( setenforce 1 ).

If you run SELinux on a production system and would not like to have attackers be able to switch back to permissive mode (even when they would have the necessary privileges otherwise), set the <tt>secure_mode_policyload</tt> boolean. When enabled, enforcing mode cannot be disabled anymore (until you reboot).

Logons through xdm (or similar) fail
If you log on through xdm, gdm, kdm, slim or any other graphical logon manager, you might notice in permissive mode that your context is off, and in enforcing mode that you just cannot log on.

The reason of this is that PAM needs to be configured to include SELinux awareness in your session handling:

Replicate the calls towards in the various  files (or similar depending on your graphical logon manager).

What is SELinuxfs and where should it be?
The selinuxfs is, as the name suggest, the SELinux File System. It is a pseudo-filesystem, which means that it is represented through files and directories, but those files or directories are not on your disk, but generated by the Linux kernel every time you query it.

The file system is used by the SELinux utilities as an interface to query the SELinux state, maintained by the Linux kernel.

Historically (before ), the mount point for the SELinux file system had to be. From onwards, the default location where the file system is looked for is, although the library still falls back to the original  location if it cannot find it at the new place.

However, the location currently has an issue for those systems not using an initramfs, as it means that  has not been mounted when <tt>init</tt> tries to mount. We are working out how to resolve this, but for now, keep active.

How do I reload all SELinux policy modules?
By default, Gentoo incrementally updates the SELinux policy. This is because the SELinux policy is modularly, starting with a setting and then several individual SELinux policy modules. When you install a SELinux policy package, it first tries to load the individual SELinux policy module. If that fails however, it will try to (re)load the entire policy (base with all installed policy modules), akin to the following:

Or, if you have unconfined domains:

Failures that occur now usually mean that not all SELinux policy modules have been upgraded yet, or that there are locally created policies loaded which cannot coexist with the newly defined SELinux policies.

Why can't I just './service start' when I am inside /etc/init.d?
For the more verbose explanation, see. Basically, running services requires a few domain transitions, assisted by the <tt>run_init</tt> command. This command first changes the working directory to before actually running the requested service. As a result, it tries to execute <tt>./service start</tt> from within instead of, resulting in an execution failure.

File labels do not seem to be set anymore, and matchpathcon sais < >
When files seem to be labeled <tt>portage_tmp_t</tt>, check with the matchpathcon command what SELinux thinks the label should be:

If that occurs, it might be a pcre upgrade that broke the binary compiled expressions. Go to the policy context directory (like ) and rebuild all files that also have a companion file with the extension:

With this done, the <tt>matchpathcon</tt> command should reveal the right context again, and you can relabel the package(s) that had wrong labels:

See also for more information.