| 1 |
On Sat, Nov 03, 2012 at 10:45:44AM -0700, "Paweł Hajdan, Jr." wrote: |
| 2 |
> On 11/3/12 10:33 AM, bugzilla-daemon@g.o wrote: |
| 3 |
> > https://bugs.gentoo.org/show_bug.cgi?id=436474 |
| 4 |
> > |
| 5 |
> > Sven Vermeulen changed: |
| 6 |
> > |
| 7 |
> > What |Removed |Added |
| 8 |
> > ---------------------------------------------------------------------------- |
| 9 |
> > Status|IN_PROGRESS |RESOLVED |
| 10 |
> > Resolution|--- |TEST-REQUEST |
| 11 |
> > |
| 12 |
> > --- Comment #11 from Sven Vermeulen --- |
| 13 |
> > In hardened-dev, r6 release |
| 14 |
> |
| 15 |
> Thank you for getting things fixed! I appreciate that. |
| 16 |
|
| 17 |
It's not fixed, the problem is possibly resolved and is now put in the |
| 18 |
TEST-REQUEST phase. |
| 19 |
|
| 20 |
> One note though: why not push policy fixes to main tree, ~arch or hard |
| 21 |
> masked? See Diego's post |
| 22 |
> <http://blog.flameeyes.eu/2010/08/fixed-in-overlay-read-not-fixed> - and |
| 23 |
> I agree with most of it. |
| 24 |
|
| 25 |
This is due to testing. I test policies locally in a few VMs to have some |
| 26 |
confidence that they are still ok. Once I think they are ok, I push it out |
| 27 |
to the hardened-dev overlay. Then my other test systems pick up the changes |
| 28 |
and do some more testing (such as migration tests, in this case from r5 to |
| 29 |
r6 in ~arch and some even from r5 to r6 in stable where only the SELinux |
| 30 |
policies are accepted for ~arch). |
| 31 |
|
| 32 |
This also allows others, with different set of systems, to try out the |
| 33 |
changes. This gives a broader coverage of the changes and allows users that |
| 34 |
want to verify their changes to pull them in from the overlay. Also, since |
| 35 |
policies can make changes on the system that do not allow for easy reverting |
| 36 |
(sometimes policies introduce new types and assign them to files, if you |
| 37 |
revert, those files have a label SELinux doesn't understand and SELinux |
| 38 |
prohibits accessing those files) I have to do sufficient testing without |
| 39 |
influencing too many users. Hence, hardened-dev overlay. |
| 40 |
|
| 41 |
Once they have been in hardened-dev overlay for a few days, most testing is |
| 42 |
done and I move it to the main tree, ~arch'ed with bugstatus "VERIFIED |
| 43 |
TEST-REQUEST". Then, after two weeks or so, the changes go to the stable |
| 44 |
set. |
| 45 |
|
| 46 |
This 14-days stabilization has been sent to the gentoo-project mailinglist. |
| 47 |
|
| 48 |
I *could* do this on a private overlay for testing, but then I really need |
| 49 |
to get those 7-ish people that test hardened-dev policies for me to use my |
| 50 |
overlay instead. And since we already have an overlay, why create another |
| 51 |
one? |
| 52 |
|
| 53 |
Also, I *could* not change the bugs until they hit ~arch, but then the users |
| 54 |
that want to verify the changes are ok do not have the ability until it hits |
| 55 |
~arch. And when it hits ~arch and the changes are bad and incompatible with |
| 56 |
the previous release, then all hell breaks loose. |
| 57 |
|
| 58 |
> Note that when you change eclasses or toolchain, it makes sense to test |
| 59 |
> in an isolated overlay. But when the in-tree policy for chromium is |
| 60 |
> unusable anyway, why not just push a new version there? |
| 61 |
|
| 62 |
SELinux policy changes are much like toolchain - it affects everyone that |
| 63 |
uses it. Unlike a non-core package change, which is isolated, SELinux policy |
| 64 |
changes affect all SELinux users. And like the toolchain you want to have |
| 65 |
some broader testing coverage to catch potential issues before unleashing it |
| 66 |
to the wider public, since a broken SELinux/toolchain might force people |
| 67 |
into rescue attempts (toolchain not working, nothing installs; SELinux not |
| 68 |
working, nothing works). |
| 69 |
|
| 70 |
True, depending on your kernel configuration, you can disable SELinux to |
| 71 |
working around things and when a new policy hits the tree, rerun parts of |
| 72 |
the SELinux installation instructions to get back on your feet. But some |
| 73 |
systems (I have four currently, not calling them production systems but they |
| 74 |
do host websites or parts of websites for around 20 organizations on the |
| 75 |
Internet) would rather not run with SELinux disabled... |
| 76 |
|
| 77 |
I hope that clarifies things. So in short: I use hardened-dev overlay to |
| 78 |
stage my changes so other test systems I and others have can test for |
| 79 |
regressions before it hits ~arch as policy changes are not easily |
| 80 |
revertible. |
| 81 |
|
| 82 |
Wkr, |
| 83 |
Sven Vermeulen |
Archives