Statement precedence/priority (neverallow)

[Stephen Smalley]

On Tue, 2010-09-21 at 12:18 +0100, Mr Dash Four wrote:
> In the standard policy most of the kernel/service modules allow access 
> to unlabelled traffic, interfaces and nodes.
> 
> I have a simple question regarding this: if I were to write an 
> additional module and include neverallow statement to deny previously 
> granted access to such resources would this be enough (my understanding 
> of neverallow is that it just checks whether previous 'allow' statements 
> were issued and if so, generates a warning and stops)?
> 
> If neverallow is not the way to go, what could I do, short of altering 
> every single policy file and remove the appropriate allow statements, to 
> disable such access to the above resources?

neverallow rules are not "deny" rules but are instead assertions on the
policy that will prevent compiling/linking from completing.  And Fedora
disables the neverallow checking these days (via expand-check=0
in /etc/selinux/semanage.conf) because it was a) slow, and b) generally
not useful to end users (vs. policy developers, who can use the 'make
validate' refpolicy Makefile target to force a check or can edit their
semanage.conf files to match their needs).

There is work in progress for policy language support for
transformations of policy, including the ability to delete rules, but it
is still in the early development stages.

For what you want to do, there is unfortunately no good mechanism at
present other than creating your own custom policy.

What you might do though is to wrap the problematic allow rules under
tunable_policy blocks with some new policy boolean, and then you could
enable/disable those rules by setting the boolean.  That might be
acceptable as a patch to the current policy that wouldn't disrupt
current users.

-- 
Stephen Smalley
National Security Agency