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
