Skip to content

SELinux insides – Part2: Neverallow assertions

September 9, 2015

Usually if we describe how to create a local policy, how to generate a new policy, how to add additional rules, we always talk about ALLOW rules and sometimes about DONTAUDIT rules. But we have another Access Vector (AV) rules – AUDITALLOW and NEVERALLOW.

ALLOW allows defined rules
DONTAUDIT stops the auditing of denial messages
AUDITALLOW audits events defined by a rule
NEVERALLOW specifies that an allow rule must not be generated for the operation

In this blog post, I would like to describe more details about NEVERALLOW rules on real examples and announce that we turn them back on in Fedora 23/Rawhide.

But why do we need to have NEVERALLOW rules/assertions? The answer is pretty easy. We need to be sure that we do not allow any unwanted/unsecure/dangerous actions. For example, we do not want to allow ordinary services to access /etc/shadow and NEVERALLOW assertions give us this ability. In the policy, we declare rules like

neverallow ~can_read_shadow_passwords shadow_t:file read;

It ensures that the policy will not contain rules allowing any domain without can_read_shadow_passwords attribute read access to /etc/shadow (otherwise the policy won’t compile).

What does it mean in practice? We can demonstrate it with the following rules on a system where NEVERALLOW assertion checks are enabled.

$ cat neverallow_test.cil
(allow sssd_t shadow_t (file (read)))

$ sudo semodule -i neverallow_test.cil
Neverallow found that matches avrule at line 310 of /var/lib/selinux/targeted/tmp/modules/100/authlogin/cil
Binary policy creation failed at line 1 of /var/lib/selinux/targeted/tmp/modules/400/neverallow_test/cil
Failed to generate binary

against

$ cat neverallow_test.cil
(typeattributeset can_read_shadow_passwords (sssd_t))
(allow sssd_t shadow_t (file (read)))

$ sudo semodule -i neverallow_test.cil
$ sesearch -A -s sssd_t -t shadow_t
allow sssd_t shadow_t : file read ;

In the first case, we were not able to define ALLOW rule because of existing NEVERALLOW rule in the policy. In the second case, we assigned can_read_shadow_passwords attribute to sssd_t to pass this NEVERALLOW rule.

As I mentioned above we turned this assertion check back on in Fedora 23/Rawhide with a new 2.4 userspace release which contains some optimalization in libsepol. Before that it took a long time to get a build of Fedora distribution policy with enabled NEVERALLOW check.

SEMOD_EXP="/usr/bin/semodule_expand -a"

was a part of our Fedora selinux-policy.spec file.

$ man semodule_expand
-a Do not check assertions. This will cause the policy to not check any neverallow rules.

Together with that we also changed to not check policy assertions during load, by setting expand-check=0 in /etc/selinux/semanage.conf. This option affects our practice examples.

So for a long time we did not have this check and we needed to be really careful with a rules which could conflict with defined assertions in the policy. With the latest Fedora SELinux userspace and policy packages, we no longer use “-a” option in selinux-policy.spec file and we modified semanage.conf to contain expand-check=1.

Advertisements

From → Uncategorized

One Comment
  1. Gran trabajo .. Gracias

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: