On Mon, Apr 09, 2018 at 01:41:12PM +0200, Lukas Vrabec wrote:
... snip ...
Those wiki pages on SELinuxProject/cil are now pretty out of date
(you'll notice that some other statements mentioned there like
`template` are not implemented as well). The updated documentation is
at https://github.com/SELinuxProject/selinux/tree/master/secilc/docs.
Hi Dominick,
Yes, This is one of the options to create hierarchy when the block on
top will have just minimum rules and every child block will append new
rules.
Unfortunately, this probably won't work in real world. Let's say that I
have this hierarchy and badlogger block contains several allow rules and
I want to inherit all of them except one, *BUT* I'm not SELinux policy
expert and don't know how hierarchy looks like. That's the reason why
I'm looking for blockinheritfilter.
I think it's more reasonable for someone not intimate with the policy to
familiarize themselves with the hierarchy/composition of a well structured
policy, rather than what they may need to disallow in a given scope (which may
come from other inherited blocks, calls to macros, or `in` statements scattered
across several policy modules). This means they can compose their policy out
of high level building blocks rather than low level allow rules (which arguably
would require a policy expert to fully understand the implications of).
"blockinheritfilter" also seems to be at odds with the permission
whitelisting/deny-by-default model of SELinux by having the policy author
revoke permissions rather than permit them.
Thanks,
Gary.
However, we should go via creating block namespaces hierarchy as you
described if there are no plans to implement this feature.
Thanks,
Lukas.
--
Lukas Vrabec
Software Engineer, Security Technologies
Red Hat, Inc.
