On Sat, Nov 03, 2012 at 10:45:44AM -0700, "Paweł Hajdan, Jr." wrote: > On 11/3/12 10:33 AM, [email protected] 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
