Mailing List Archive

On Sat, Nov 03, 2012 at 10:45:44AM -0700, "Paweł Hajdan, Jr." wrote:
> On 11/3/12 10:33 AM, bugzilla-daemon@gentoo.org wrote:
> > https://bugs.gentoo.org/show_bug.cgi?id=436474
> >
> > Sven Vermeulen changed:
> >
> > What |Removed |Added
> > ----------------------------------------------------------------------------
> > Status|IN_PROGRESS |RESOLVED
> > Resolution|--- |TEST-REQUEST
> >
> > --- Comment #11 from Sven Vermeulen ---
> > In hardened-dev, r6 release
>
> Thank you for getting things fixed! I appreciate that.

It's not fixed, the problem is possibly resolved and is now put in the
TEST-REQUEST phase.

> One note though: why not push policy fixes to main tree, ~arch or hard
> masked? See Diego's post
> <http://blog.flameeyes.eu/2010/08/fixed-in-overlay-read-not-fixed> - and
> I agree with most of it.

This is due to testing. I test policies locally in a few VMs to have some
confidence that they are still ok. Once I think they are ok, I push it out
to the hardened-dev overlay. Then my other test systems pick up the changes
and do some more testing (such as migration tests, in this case from r5 to
r6 in ~arch and some even from r5 to r6 in stable where only the SELinux
policies are accepted for ~arch).

This also allows others, with different set of systems, to try out the
changes. This gives a broader coverage of the changes and allows users that
want to verify their changes to pull them in from the overlay. Also, since
policies can make changes on the system that do not allow for easy reverting
(sometimes policies introduce new types and assign them to files, if you
revert, those files have a label SELinux doesn't understand and SELinux
prohibits accessing those files) I have to do sufficient testing without
influencing too many users. Hence, hardened-dev overlay.

Once they have been in hardened-dev overlay for a few days, most testing is
done and I move it to the main tree, ~arch'ed with bugstatus "VERIFIED
TEST-REQUEST". Then, after two weeks or so, the changes go to the stable
set.

This 14-days stabilization has been sent to the gentoo-project mailinglist.

I *could* do this on a private overlay for testing, but then I really need
to get those 7-ish people that test hardened-dev policies for me to use my
overlay instead. And since we already have an overlay, why create another
one?

Also, I *could* not change the bugs until they hit ~arch, but then the users
that want to verify the changes are ok do not have the ability until it hits
~arch. And when it hits ~arch and the changes are bad and incompatible with
the previous release, then all hell breaks loose.

> Note that when you change eclasses or toolchain, it makes sense to test
> in an isolated overlay. But when the in-tree policy for chromium is
> unusable anyway, why not just push a new version there?

SELinux policy changes are much like toolchain - it affects everyone that
uses it. Unlike a non-core package change, which is isolated, SELinux policy
changes affect all SELinux users. And like the toolchain you want to have
some broader testing coverage to catch potential issues before unleashing it
to the wider public, since a broken SELinux/toolchain might force people
into rescue attempts (toolchain not working, nothing installs; SELinux not
working, nothing works).

True, depending on your kernel configuration, you can disable SELinux to
working around things and when a new policy hits the tree, rerun parts of
the SELinux installation instructions to get back on your feet. But some
systems (I have four currently, not calling them production systems but they
do host websites or parts of websites for around 20 organizations on the
Internet) would rather not run with SELinux disabled...

I hope that clarifies things. So in short: I use hardened-dev overlay to
stage my changes so other test systems I and others have can test for
regressions before it hits ~arch as policy changes are not easily
revertible.

Wkr,
Sven Vermeulen