How SELinux deny rules improve system security

SELinux userspace release 3.6 introduces deny rules. SELinux is designed as an additional layer of system security. SELinux policy defines the access and operations (e.g., read or write) allowed for certain resources. SELinux stops all access unless allowed by policy.

Before the SELinux 3.6 userspace version, it was not possible to drop any access already allowed in the base SELinux policy or in a module. When you wanted to remove access, you had to rewrite the base policy or the module. This would mean maintaining your own policy or module and overriding the distribution policies. While it’s feasible, it costs resources and could be error-prone, because you would need to merge distribution changes with your own.

How deny rules work

The changes in the latest SELinux userspace release 3.6 introduced support for deny rules. They are documented in Access Vector Rules: "Remove the access rights defined from any matching allow rules. These rules are processed before neverallow checking."

Rule definition:

(deny source_id target_id|self classpermissionset_id ...)

A deny rule is like a neverallow rule, except it removes permissions rather than reporting errors.

Let’s consider the following use cases.

Restricted users

As an administrator, I need to limit confined users so that they cannot run the ssh command.

The /usr/bin/ssh is labeled with the ssh_exec_t file context. By default, user_u users are allowed to execute files with this context:

# sesearch -A -s user_t -t ssh_exec_t
...
allow user_usertype application_exec_type:file { execute execute_no_trans getattr ioctl lock map open read };

In order to block user_u users to execute them, we need to deny these permissions:

# cat > deny_user_t_ssh_exec_t.cil <<EOF
(deny user_t ssh_exec_t (file (execute execute_no_trans getattr ioctl lock map open read)))
EOF
# semodule -i deny_user_t_ssh_exec_t.cil

If a user tries to use ssh now they get Permission denied:

user@localhost:~$ /usr/bin/ssh localhost
-bash: /usr/bin/ssh: Permission denied

Restricted system admin

As an administrator, I need to have another administrator assigned to sysadm_u who would not be able to read user homedir data.

We’ll create a new user sysadm mapped to the SELinux user staff_u, allow them to become root by running sudo assysadm_t, and check whether they’re allowed to read homedir:

# useradd -Z staff_u sysadm
# passwd sysadm
New password:
BAD PASSWORD: The password is shorter than 8 characters
Retype new password:
passwd: password updated successfully
# cat > /etc/sudoers.d/sysadm <<EOF
sysadm ALL=(ALL) TYPE=sysadm_t ROLE=sysadm_r ALL
EOF
# ssh sysadm@localhost
sysadm@localhost's password:
sysadm@localhost:~$ id -Z
staff_u:staff_r:staff_t:s0-s0:c0.c1023
sysadm@localhost:~$ sudo -i
[sudo] password for sysadm:
root@localhost:~# id -Z
staff_u:sysadm_r:sysadm_t:s0-s0:c0.c1023
root@localhost:~# ls /home/
bachradsusi  mock  plautrba  sysadm  user
root@localhost:~# ls /home/user
Desktop  Documents  Downloads  linux-system-roles-selinux  Music  Pictures  Public  Templates  Videos

Apparently, sysadm can read other user homes so we need to drop permissions:

# cat > deny_sysadm_user_home_dir_t.cil <<EOF
(deny sysadm_t user_home_dir_t (dir ( add_name append audit_access create execmod execute getattr ioctl link lock mounton open quotaon read relabelfrom relabelto remove_name rename reparent rmdir search setattr swapon unlink watch watch_mount watch_reads watch_sb watch_with_perm write )))
EOF
# semodule -i deny_sysadm_user_home_dir_t.cil
# sesearch -A -s sysadm_t -t user_home_dir_t -c dir
#

root@localhost:~# ls /home/user
ls: cannot access '/home/user': Permission denied

It looks good. But what happens if the user switches to permissive as follows:

root@localhost:~# setenforce 0
root@localhost:~# ls /home/user
Desktop  Documents  Downloads  linux-system-roles-selinux  Music  Pictures  Public  Templates  Videos

As you can see, a simple deny rule is not necessarily a good tool when used on privileged SELinux domains, which can manipulate SELinux settings on the hosts.

Hardening the default policy

Sometimes, the default SELinux policy allows users to hang a system. For example, when an unconfined user tries to ptrace fapolicyd. Although you could disallow ptrace for the whole system by using the deny_ptrace boolean, it’s not necessary to limit ptrace of other daemons. To limit ptrace and signals on fapolicyd, we can use a deny rule.

This module is actually already shipped with the fapolicyd policy with PR add fapolicyd-hardening module preventing usage of sigstop, sigkill and ptrace.

But you could do the same thing manually.

# cat > deny_domain_fapolicyd_ptrace.cil <<EOF
(deny domain fapolicyd_t ( process ( ptrace sigkill sigstop ) ) )
EOF
# semodule -i deny_domain_fapolicyd_ptrace

Learn more

SELinux userspace release 3.6 introduces deny rules. This article demonstrated how you can now remove SELinux permissions from the base SELinux policy or a module. This improves system security and reduces errors and costs.

To learn more about SELinux, check out the SELinux documentation.