Portal:SELinux/Common issues

Common Issues

The openSUSE SELinux policies have been tuned to provide as good protection as possible for most users. This means that potentially dangerous functionality not needed by the majority of users is disabled by default.

Sometimes, however, it is needed to tweak your SELinux policy for a specific workload. This is a general design principle of SELinux, which means it is encouraged to adapt the rules when needed.

This list provides an overview of common "issues", that can be solved by adapting the SELinux policy on the user's end.

SELinux booleans

SELinux booleans provide a simple way for the user to toggle some optional functionality in the SELinux policy, without having to add or modify policy modules. Booleans make it easy for policy writers to account for and support situations which are only needed by specific users for specific workloads, without compromising the security of all other users in the general case.

execheap, execmod, execstack booleans

The execheap, execmod, and execstack booleans are an example of this, in the sense that they allow behaviour which is generally dangerous, and not needed by normal Linux applications. As such, they are disabled by default. However, there are specific applications, workloads and circumstances where they can be useful or necessary. In these cases, the user can evaluate the risks and decide to enable the boolean on their system.

You can refer to bug 1206292 for further information.

A list of applications that have been reported to possibly need these permissions is presented below. This list is not complete, but might help you to troubleshoot these or similar applications.

Steam Proton, Bottles, WINE, Lutris, not working from flatpaks

If you run into issues using WINE, and WINE based programs in flatpaks, it could be due to SELinux preventing execution of modified memory-mapped files (execmod). If you understand the risks, you can allow this on your system temporarily (resets on next boot) with

sudo setsebool selinuxuser_execmod 1

Or permanently with:

sudo setsebool -P selinuxuser_execmod 1

Team Fortress 2 missing audio

If you run into audio issues with Team Fortress 2, it could be due to SELinux preventing heap execution (execheap). If you understand the risks, you can allow this on your system temporarily (resets on next boot) with

sudo setsebool selinuxuser_execheap 1

Or permanently with:

sudo setsebool -P selinuxuser_execheap 1

Android Studio emulator not working from flatpak

If you run into issues using Android studio emulator in flatpaks, it could be due to SELinux preventing stack execution (execstack). If you understand the risks, you can allow this on your system temporarily (resets on next boot) with

sudo setsebool selinuxuser_execstack 1

Or permanently with:

sudo setsebool -P selinuxuser_execstack 1

xen: Allow qemu to run as daemon

xen runs qemu as daemon via systemd when used in xen as dom0 disk backend (see xen-qemu-dom0-disk-backend.service).

This is currently not allowed by default. To allow this, enable the boolean xen_use_qemu_for_dom0_disk_backend:

sudo semanage boolean -m --on xen_use_qemu_for_dom0_disk_backend
sudo restorecon -Rv /var/lib/xen/xenstore

Please refer to bug 1228540 for more information.

Non-standard file locations

Especially when using btrfs filesystems, it may be desirable to store some data in non-standard locations. One cause for such a measure, is to optimise btrfs performance, such as to store virtual machines, containers or databases, in volumes without copy-on-write enabled. Another common cause, is to avoid certain data from being included in snapshots.

Common to all filesystems, it is very common for a user's directories to be relocated. For example, xdg-user-dirs-update exists for this purpose, but is not SELinux-aware.

The system administrator who alters these locations, must take care of SELinux file context labeling, to ensure correct functionality. It should be noted that some of the SELinux tools will not function correctly across btrfs subvolume boundaries, instead treating them as separate filesystems, and failing to label files within them. See Bug 1228849 for details.

One method to deal with this is to create an SELinux file context equivalence. This means telling SELinux to consider one directory equivalent to another for labeling purposes.

First, we can create an equivalence:

sudo semanage fcontext --add --equal "/path/to/stock/directory" "/path/to/custom/location/you/want/to/act/like/stock"

Test it out to see what would change, without changing anything:

sudo restorecon -Rvn "/path/to/custom/location/you/want/to/act/like/stock"

Apply the changes:

sudo restorecon -R "/path/to/custom/location/you/want/to/act/like/stock"

Manage equivalances we have created:

sepolicy gui

or

sudo semanage fcontext --list -C

An alternative to creating an equivalence is to specify the context directly, if it is known. The following sets selinux_foo_t labels on the directory /path/to/virtual/machine/images, and all of its contents:

sudo semanage fcontext -a -t selinux_foo_t "/path/to/virtual/machine/images(/.*)?"
sudo restorecon -Rvn /path/to/virtual/machine/images
sudo restorecon -R

Below are common examples on how to fix these issues.

snapper does not work on non-standard snapshot location

snapper needs a specific type for its snapshot location (see openQA test issue 168583). For example, when adding the snapshot to a directory /test, the file context needs to be set like this:

 semanage fcontext -a -t 'snapperd_data_t' -s system_u '/test(/.*)?'
 semanage fcontext -a -t '<<none>>' -s system_u '/test/[^/]*/snapshot(/.*)?'

quota does not work on non-standard location

quota needs a specific type for its database location (see openQA test issue 175338). For example, when adding the database to a directory /test, the file context needs to be set like this:

 semanage fcontext -a -t quota_db_t /test/quota/aquota.user
 semanage fcontext -a -t quota_db_t /test/quota/aquota.group

rsync does not work with SELinux

When using a non-standard path for rsync (e.g. /srv/rsync_test), you will need to set the file context for the directory (see openQA test issue 175890):

 semanage fcontext -a -t rsync_data_t "/srv/rsync_test(/.*)"

samba/cifs does not work with SELinux

When using samba shares (e.g. in /srv/samba), you will need to set the file context for the share as there is no default location (see openQA test issue 175839):

 semanage fcontext -a -t samba_share_t "/srv/samba(/.*)"

Non-standard port

When running services that are listening on a non-standard port, the system administrator needs to set a SELinux rule to allow connections on that port.

SELinux denials for webserver with non-standard port

When running a webserver on a non-standard port, you will need to tweak the SELinux policy by allowing the port:

 sudo semanage port -a -t http_port_t -p tcp 444

(see openQA test issue 168580)