selinux.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stephen Smalley <sds@tycho.nsa.gov>
To: Chris PeBenito <pebenito@ieee.org>, Joe Nall <joe@nall.com>,
	selinux@vger.kernel.org
Subject: Re: neverallow rules
Date: Wed, 27 Feb 2019 08:29:13 -0500	[thread overview]
Message-ID: <f1d65c8e-4490-5df0-7ba5-b589e3d85713@tycho.nsa.gov> (raw)
In-Reply-To: <6d65bb0be6bd5ccbdb1f99a646679e21955d6159.camel@ieee.org>

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

  reply	other threads:[~2019-02-27 13:33 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-27  1:29 neverallow rules Joe Nall
2019-02-27  3:38 ` Chris PeBenito
2019-02-27 13:29   ` Stephen Smalley [this message]
2019-02-27 13:48     ` Stephen Smalley
2019-02-27 13:54       ` Stephen Smalley
2019-02-27 13:57         ` Stephen Smalley
2019-02-27 14:12           ` Stephen Smalley
2019-02-27 16:13   ` [Non-DoD Source] " jwcart2

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f1d65c8e-4490-5df0-7ba5-b589e3d85713@tycho.nsa.gov \
    --to=sds@tycho.nsa.gov \
    --cc=joe@nall.com \
    --cc=pebenito@ieee.org \
    --cc=selinux@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).