Re: neverallow rules

[Stephen Smalley <sds@tycho.nsa.gov>]

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