On 2/27/19 8:57 AM, Stephen Smalley wrote:
On 2/27/19 8:54 AM, Stephen Smalley wrote:
On 2/27/19 8:48 AM, Stephen Smalley wrote:
On 2/27/19 8:29 AM, Stephen Smalley wrote:
On 2/26/19 10:38 PM, Chris PeBenito wrote:
On Tue, 2019-02-26 at 19:29 -0600, Joe Nall wrote:
Looking at neverallow rules, the semanage.conf file says
"# expand-check check neverallow rules when executing all semanage
commands.
# Large penalty in time if you turn this on. "
If I don't set expand-check=1, are the neverallow rules actually
enforced?
Nope.
If so, when?
An semodule -i of a policy module with neverallow rules that are
violated by the existing binary policy succeeds without complaint
unless expand-check=1 in RHEL 7.6. This is not what I expected.
The time taken by a trivial module installation goes from ~.3 seconds
to ~14 seconds, so the time hit for expand-check is pretty serious.
The reason for adding the expand-check option is because the
neverallow
checking is so expensive.
We are trying to establish some policy invariants to protect against
unexpected/unnoticed RHEL upstream policy changes, some of which have
bitten us recently. Any suggestions are welcome.
One alternative would be to use the setools API to code up some policy
searches in Python, then process the results to find things you
do/don't want in your policy.
The approach taken in Fedora/RHEL is to run make validate as part of
the selinux-policy.spec recipe, which uses the validate target in
the refpolicy Makefile, which manually runs semodule_link and
semodule_expand to manually link and expand the modules and performs
full checking. Then the cost is only paid at policy build time and
is only applied for the neverallow rules and allow rules in the
Fedora/RHEL policy, not for third party modules. If you are
rebuilding the RHEL policy from source, you could add your
neverallows to it there and the make validate should catch the
violations.
In Android, neverallow checking is done both at policy build time
and as part of device certification. The latter is done using a
sepolicy-analyze tool we originally contributed; it can take a
separate neverallow rule configuration in source form and an already
compiled kernel binary policy and check them against each other.
That's useful for cases where you don't have policy sources.
You can have libsemanage apply your own checker against policy as
part of module transactions by specifying a [verify kernel] stanza
in semanage.conf, see:
http://selinuxproject.org/page/PolicyValidate
Also, FWIW, you can obtain, build, and use sepolicy-analyze outside
of the Android build system as follows. If you are on RHEL 7, you
likely need/want to obtain the upstream selinux userspace and build
its version of libsepol.a for use below instead of using the
libsepol-static package from RHEL since that is likely too old.
# Get source and build.
$ git clone https://android.googlesource.com/platform/system/sepolicy
$ cd sepolicy/tools/sepolicy-analyze
$ gcc -o sepolicy-analyze *.c /path/to/libsepol.a
# Run with neverallows specified on the command-line.
$ sepolicy-analyze /etc/selinux/targeted/policy/policy.31 neverallow
-n "neverallow user_t self:process signal;"
# Run with neverallows from a separate file.
$ cat > neverallows.conf <<EOF
neverallow user_t self:process signal;
EOF
$ sepolicy-analyze /etc/selinux/targeted/policy/policy.31 neverallow
-f neverallows.conf
There have been improvements to neverallow checking time upstream
since RHEL 7, but it will still be a function of policy size and
obviously RHEL has a much larger policy than Android...
For reference, on Fedora 29:
$ time sepolicy-analyze /etc/selinux/targeted/policy/policy.31
neverallow -n "neverallow user_t self:capability mac_admin;"
real 0m0.145s
user 0m0.133s
sys 0m0.012s
Also, you can put multiple neverallow statements (semicolon separated)
in the -n option value and have them all checked at once, or similarly
multiple ones in the file.
There is an error in the example above; mac_admin is a permission in
capability2 rather than capability. By default, sepolicy-analyze
doesn't warn about undefined classes/permissions/types because a given
binary policy might not define everything used in a neverallow
configuration and that is ok (i.e. if there is no matching type, class
or permission, then it isn't possible for the neverallow to be
violated). If you want it to detect such things, pass -w to neverallow, ala:
$ sepolicy-analyze /etc/selinux/targeted/policy/policy.31 neverallow -w
-n "neverallow user_t self:capability mac_admin;"
Warning! Permission mac_admin used in neverallow undefined in class
capability in policy being checked.
Warning! Empty permission set
These are only warnings however; they do not yield an error exit.
