Re: [gentoo-hardened] Feedback on article recommending Gentoo for SELinux

[Sven Vermeulen <sven.vermeulen@siphos.be>]

On Mon, Jul 13, 2015 at 3:51 PM, Jason Zaman <perfinion@gentoo.org> wrote:
> On Mon, Jul 13, 2015 at 03:02:55PM +0200, Sven Vermeulen wrote:
>> On Mon, Jul 13, 2015 at 1:31 PM, Jason Zaman <perfinion@gentoo.org> wrote:
>> > Secondly, related to "poor support for preserving local changes across
>> > system updates". The tools now have the concept of priority so users can
>> > easy completely replace a distro-provided module at a higher priority
>> > (semodule -X 900 -i foo.pp). I haven't (yet) updated our selinux eclass
>> > to install at a lower priority but will hopefully do that soon.
>>
>> We work with the default 400 (100 is for the migrated modules). Do you
>> see a reason why we have to explicitly support a particular priority
>> in our eclass?
>
> Hmm. I thought the point of the priorities was that things the user has
> done should be separate from what the distro provides. Either the distro
> uses 400 and any overrides the user does in a higher level or we change
> the eclass to use a lower level and the user gets the default. That way
> its easier for the user to see what customizations have been made.
>
> I was going to make a patch first then discuss but the basic idea was to
> semodule -X 100 -i $MOD.pp then remove the module from level 400
> afterwards if it exists. Thoughts? And if we do, do we want to use level
> 100? 200?

I think that it is sufficient to inform users that they can override
modules by picking a level higher than 400. If we would use a lower
value ourselves, we should've done that before the 2.4 migration went
stable and with sufficient documentation support. And I'm personally
not convinced we should go that route anyway.

If we implement logic right now, then how would we make sure that this
logic is only executed once? You'd need to hack some logic in the
(already somewhat complex) eclass to only do this once (if
successfull). And to what benefit?

The priority stuff is nice, but I find that it is somewhat a feature
that was implemented "because it was easy" and not because it is well
thought through (sorry for whomever implemented it - nothing
personal). Policy developers and users who do some policy enhancements
(which is the scope of the exercise we're talking about) who want to
overrule an existing policy will want to still benefit from evolutions
in the interfaces that they call. But that isn't the case, because
interface updates require rebuilds of the policy (CIL *might* remove
this obstacle depending on the implementation).

In other words, if I overrule the xserver module with my own, and the
init_daemon_domain() interface is updated, then this update will not
be taken into account. Whereas within Gentoo, we do a full policy
update (revbump) to make sure that updates on the interfaces are taken
up.

The priority stuff makes more sense in a managed environment, for
instance where you do policy "upgrades" and validate if things still
work properly. If they don't, unload them again, otherwise unload the
previous versions of the modules. But this needs to be managed and
supported. Right now, I'm guessing 95% of our users still have their
old policy in the 100-range.

Remember the kdevtmpfs related patch I once suggested to the eclass?
[1] Its horrible code, and this one didn't have to deal with "just
doing this once".

[1] https://archives.gentoo.org/gentoo-hardened/message/08b8c81d79720857045d762bb8cdbf62

I think we should put our focus elsewhere. Module priorities are nice,
but are not the innovative solution that our users are waiting for.

Unlike some of the CIL promises that we still need to see land ;-)

Wkr,
  Sven Vermeulen