[gentoo-project] Faster stabilization of SELinux policies

[Sven Vermeulen]

I'm hoping this is sufficiently "non-technical" to be on -project ;-)

SELinux uses a "deny all by default" principle, which means that anything
that isn't explicitly allowed is denied. When a policy (i.e. the rules that
the system and its processes need to adhere to) is updated, it usually is
enhanced (more rights added) rather than reduced (rights removed). This is
mainly because it is hard to find out which rules can be removed without
risk of introducing regressions.

When things change on a system (we've had a few in the near past, think about
udev binary move, /run introduction, /usr merge, ...) the policies almost
always need to be changed. Sadly, these changes are often faster brought
into the stable tree than I can detect. I try to reduce the likelihood of
this with more automated infrastructural tests and autobuilds, but things do
fall through (for instance, /run issues only coming up when /var/run is a
symlink, which isn't the case for "older" installations).

To still support stable users, I currently use the "standard" 30-day
stabilization period for the policies, but when I know the "pending stable"
policy has other issues (it fixes /run, but now also needs the udev-binary
move) I start the 30-day counter on the next policy. As a result, stable
users are often "forced" to use ~arch policies.

I would like to use a 14-day stabilization period instead. Why shorter?
Well, first of all, there is already a period of testing within the
hardened-dev overlay. Also, as policies are usually updated (enhanced) the
risk of introducing regressions (in the policy that is) is low. Finally,
it'll allow stable users to get their needed updates.

There will be policy changes for which I'll use a 30-day period. For
instance, when core system confined domains are rewritten (or split) or when
some rights have been removed. This is also why I rather not have all users
always use ~arch because there will be times that the policies get more
thorough changes.

This has been discussed on the last hardened meeting where everyone agreed
on, and I'm hoping I can get your support for this as well.

Wkr,
	Sven Vermeulen