SELinux/FAQ

From Gentoo Wiki
Jump to: navigation, search

Contents

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 handbook, 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.

General SELinux Support Questions

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 as it would be redundant to SELinux's access control.

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 hardened/linux/amd64/no-multilib/selinux 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.

## # The SELinux allow rule
allow foo_t bar_t:file { read };

## # This will succeed:
staff_u:staff_r:foo_t reads file with type staff_u:object_r:bar_t

## # This will be prohibited:
user_u:user_r:foo_t reads file with type staff_u:object_r:bar_t

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.

Using SELinux

How do I enable SELinux?

This is explained in the SELinux handbook in the chapter on Using Gentoo/Hardened SELinux.

How do I switch between permissive and enforcing?

The easiest way is to use the setenforce command. With setenforce 0 you tell SELinux to run in permissive mode. Similarly, with setenforce 1 you tell SELinux to run in enforcing mode.

You can also add a kernel option enforcing=0 or enforcing=1 in the bootloader configuration (or during the startup routine of the system). This allows you to run SELinux in permissive or enforcing mode from the start of the system.

The default state of the system is kept in /etc/selinux/config.

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 /etc/selinux/config and set SELINUX=disabled . Next, reboot your system.

Important
When you have been running your system with SELinux disabled, you must boot in permissive mode first and relabel your entire file system. Activities ran while SELinux was disabled might have created new files or removed the labels from existing files, causing these files to be available without security context.

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 :

root # findcon /etc/selinux/strict/contexts/files/file_contexts -p /lib64/rc/init.d
/.*                          system_u:object_r:default_t
/lib64/rc/init\.d(/.*)?   system_u:object_r:initrc_state_t
/lib64/.*                    system_u:object_r:lib_t

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

However, when you add your own file contexts (using semanage ), this does not apply. Instead, tools like restorecon will take the last hit within the locally added file contexts! You can check the content of the locally added rules in /etc/selinux/strict/contexts/files/file_contexts.local (substitute strict with your SELinux type).

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 development guide and other documentation linked from the Hardened SELinux project page.

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 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 fixlocal, substitute with whatever name you like - but keep it consistent. In the file (fixlocal.te) put in the following text (again, substitute fixlocal with your chosen name):

policy_module(fixlocal, 1.0)

require {
## # Declarations of types, classes and permissions used

}

## # Declaration of policy rules

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

  1. Allow mozilla_t the execmem privilege (based on a denial that occurs when mozilla fails to start)
  2. Allow ssh_t to connect to any port rather than just the SSH port
  3. Allows the user_t domain to send messages directly to the system logger
policy_module(fixlocal, 1.0)

require {
  type mozilla_t;
  type ssh_t;
  type user_t;

  class process { execmem };
}

## # Grant mozilla the execmem privilege
allow mozilla_t self:process { execmem };

## # Allow SSH client to connect to any port (as provided by the user through the 
## # "ssh -p <portnum> ..." command)
corenet_tcp_connect_all_ports(ssh_t)

## # Allow the user_t domain to send messages to the system logger
logging_send_syslog_msg(user_t)

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

When using interface names, make sure that the types ( ssh_t and user_t ) are mentioned in the require { ... } paragraph.

To find the proper interface name (like corenet_tcp_connect_all_ports above), you can either look for it in the SELinux Reference Policy API online or, if sec-policy/selinux-base-policy is built with the doc USE flag, in /usr/share/doc/selinux-base-policy-.*/html. 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 Makefile provided by the system:

root # make -f /usr/share/selinux/strict/include/Makefile fixlocal.pp

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.

root # semodule -i fixlocal.pp

SELinux Kernel Error Messages

I get a register_security error message when booting

During boot-up, the following message pops up:

There is already a security framework initialized, register_security failed.
Failure registering capabilities with the kernel
selinux_register_security: Registering secondary module capability
Capability LSM initialized

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:

SELinux: 2048 avtab hash slots, 16926 rules.
SELinux: 2048 avtab hash slots, 16926 rules.
SELinux:  6 users, 6 roles, 1083 types, 34 bools
SELinux:  77 classes, 16926 rules
SELinux:  Permission read_policy in class security not defined in policy.
SELinux:  Permission audit_access in class file not defined in policy.
SELinux:  Permission audit_access in class dir not defined in policy.
SELinux:  Permission execmod in class dir not defined in policy.
...
SELinux: the above unknown classes and permissions will be denied
SELinux:  Completing initialization.

This means that the Linux kernel that you are booting supports permissions that are not defined in the policy (as offered through the sec-policy/selinux-base-policy 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).

SELinux and Gentoo

I get a missing SELinux module error when using emerge

When trying to use emerge , the following error message is displayed:

!!! SELinux module not found. Please verify that it was installed.

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 relabelling the files of the portage package:

root # rlpkg portage

I get 'FEATURES variable contains unknown value(s): loadpolicy'

When running emerge, the following error is shown:

FEATURES variable contains unknown value(s): loadpolicy

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 /selinux) and make sure that /etc/make.conf does not have FEATURES="loadpolicy" 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:

filespec_add: conflicting specifications for /usr/bin/getconf and 
/usr/lib64/misc/glibc/getconf/XBS5_LP64_OFF64, using
system_u:object_r:lib_t

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:

  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 labelled 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 labelled correctly (say a binary somewhere in a /usr/lib64 location) using semanage ( semanage fcontext -a -t correct_domain_t /usr/lib64/path/to/file )

It is also not a bad idea to report (after verifying if it hasn't been reported first) this onGentoo's bugzillaso that the default policies are updated accordingly.

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:

>> Installing (1 of 1) net-dns/host-991529
>>> Setting SELinux security labels
ERROR: ld.so: object 'libsandbox.so' from LD_PRELOAD cannot be preloaded: ignored.

This message should only occur after the Setting SELinux security labels message. It happens because SELinux tells glibc to disable LD_PRELOAD (and other environment variables that are considered potentially harmful) during domain transitions. Here, portage calls the setfiles command (part of a SELinux installation) and as such transitions from portage_t to setfiles_t, 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 portage_t to setfiles_t 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 sysadm_r role. Any Portage related activity requires that you are in the sysadm_r role. To transition to the role, first validate if you are currently known as staff_u (or, if you added your own SELinux identities, a user that has the permission to transition to the sysadm_r role). Then run newrole -r sysadm_r to transition.

user $ emerge --info
user $
id -Z
user $
newrole -r sysadm_r
Password: 

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:

root # ls -Z /var/spool/cron/crontabs/root
staff_u:object_r:user_cron_spool_t /var/spool/cron/crontabs/root

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


root # getseuser root system_u:system_r:crond_t
seuser:  root, level (null)
Context 0       root:sysadm_r:cronjob_t
Context 1       root:staff_r:cronjob_t

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

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

root # chcon -u root /var/spool/cron/crontabs/root

Another workaround would be to disable UBAC completely. This is accomplished with USE="-ubac" .

When querying the policy, I get 'ERROR: could not find datum for type ...'

When using seinfo or sesearch to query the policy on the system, you get errors similar to:

root # seinfo -tasterisk_t
ERROR: could not find datum for type asterisk_t

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:

root # ls -ltr /etc/selinux/strict/policy/policy.*

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

root # cat /selinux/policyvers; echo
24

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:

File/etc/selinux/semanage.conf

## # Look for and uncomment the policy-version line and set it to the right version
policy-version = 24
Important
If your system is upgrading its kernel, higher version(s) can be supported. In this case, either unset the value again to automatically "jump" to a higher version, or force set it to the higher version.


Portage fails to label files because "setfiles" does not work anymore

Portage uses the setfiles 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 (libselinux.so, libsepol.so, libaudit.so and of course libc.so) might cause for the application to fail. Gentoo's standard solution ( revdep-rebuild ) will not work, since the tool will try to rebuild policycoreutils, which will fail to install because Portage cannot set the file labels.

The solution is to rebuild policycoreutils while disabling Portage's selinux support, then label the installed files manually using chcon , based on the feedback received from matchpathcon .

root # FEATURES="-selinux" emerge --oneshot policycoreutils
root #
for FILE in $(qlist policycoreutils); do CONTEXT=$(matchpathcon -n ${FILE}); chcon ${CONTEXT} ${FILE}; done

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 nosuid option, then applications started from these file systems will not transition into their appropriate domain. This is intentional.

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

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 system_u:system_r . 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 /etc/pam.d/run_init and adding the following line on top:

auth     sufficient     pam_rootok.so

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

root # run_init rc-service local status
Authenticating swift.
 * status: started

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 secure_mode_policyload boolean. When enabled, enforcing mode cannot be disabled anymore (until you reboot).

root # setsebool secure_mode_policyload on

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:

File/etc/pam.d/somesession

...
session  required   pam_loginuid.so
session  optional   pam_console.so
session  optional   pam_selinux.so

Replicate the calls towards pam_selinux.so in the various /etc/pam.d/gdm* 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 libselinux-2.1.9), the mount point for the SELinux file system had to be /selinux. From libselinux-2.1.9 onwards, the default location where the file system is looked for is /sys/fs/selinux, although the library still falls back to the original /selinux location if it cannot find it at the new place.

However, the /sys/fs/selinux location currently has an issue for those systems not using an initramfs, as it means that /sys has not been mounted when init tries to mount /sys/fs/selinux. We are working out how to resolve this, but for now, keep /selinux 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 base.pp 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:

root # cd /usr/share/selinux/strict
root #
semodule -b base.pp -i $(ls *.pp | grep -v unconfined | grep -v base.pp)

Or, if you have unconfined domains:

root # semodule -b base.pp -i $(ls *.pp | grep -v base.pp)

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 bug #448292. Basically, running services requires a few domain transitions, assisted by the run_init command. This command first changes the working directory to / before actually running the requested service. As a result, it tries to execute ./service start from within / instead of /etc/init.d, resulting in an execution failure.

root # cd /etc/init.d; ./sshd status
Authenticating root.
Exec:: No such file or directory