1 |
On Mon, Jul 13, 2015 at 3:51 PM, Jason Zaman <perfinion@g.o> wrote: |
2 |
> On Mon, Jul 13, 2015 at 03:02:55PM +0200, Sven Vermeulen wrote: |
3 |
>> On Mon, Jul 13, 2015 at 1:31 PM, Jason Zaman <perfinion@g.o> wrote: |
4 |
>> > Secondly, related to "poor support for preserving local changes across |
5 |
>> > system updates". The tools now have the concept of priority so users can |
6 |
>> > easy completely replace a distro-provided module at a higher priority |
7 |
>> > (semodule -X 900 -i foo.pp). I haven't (yet) updated our selinux eclass |
8 |
>> > to install at a lower priority but will hopefully do that soon. |
9 |
>> |
10 |
>> We work with the default 400 (100 is for the migrated modules). Do you |
11 |
>> see a reason why we have to explicitly support a particular priority |
12 |
>> in our eclass? |
13 |
> |
14 |
> Hmm. I thought the point of the priorities was that things the user has |
15 |
> done should be separate from what the distro provides. Either the distro |
16 |
> uses 400 and any overrides the user does in a higher level or we change |
17 |
> the eclass to use a lower level and the user gets the default. That way |
18 |
> its easier for the user to see what customizations have been made. |
19 |
> |
20 |
> I was going to make a patch first then discuss but the basic idea was to |
21 |
> semodule -X 100 -i $MOD.pp then remove the module from level 400 |
22 |
> afterwards if it exists. Thoughts? And if we do, do we want to use level |
23 |
> 100? 200? |
24 |
|
25 |
I think that it is sufficient to inform users that they can override |
26 |
modules by picking a level higher than 400. If we would use a lower |
27 |
value ourselves, we should've done that before the 2.4 migration went |
28 |
stable and with sufficient documentation support. And I'm personally |
29 |
not convinced we should go that route anyway. |
30 |
|
31 |
If we implement logic right now, then how would we make sure that this |
32 |
logic is only executed once? You'd need to hack some logic in the |
33 |
(already somewhat complex) eclass to only do this once (if |
34 |
successfull). And to what benefit? |
35 |
|
36 |
The priority stuff is nice, but I find that it is somewhat a feature |
37 |
that was implemented "because it was easy" and not because it is well |
38 |
thought through (sorry for whomever implemented it - nothing |
39 |
personal). Policy developers and users who do some policy enhancements |
40 |
(which is the scope of the exercise we're talking about) who want to |
41 |
overrule an existing policy will want to still benefit from evolutions |
42 |
in the interfaces that they call. But that isn't the case, because |
43 |
interface updates require rebuilds of the policy (CIL *might* remove |
44 |
this obstacle depending on the implementation). |
45 |
|
46 |
In other words, if I overrule the xserver module with my own, and the |
47 |
init_daemon_domain() interface is updated, then this update will not |
48 |
be taken into account. Whereas within Gentoo, we do a full policy |
49 |
update (revbump) to make sure that updates on the interfaces are taken |
50 |
up. |
51 |
|
52 |
The priority stuff makes more sense in a managed environment, for |
53 |
instance where you do policy "upgrades" and validate if things still |
54 |
work properly. If they don't, unload them again, otherwise unload the |
55 |
previous versions of the modules. But this needs to be managed and |
56 |
supported. Right now, I'm guessing 95% of our users still have their |
57 |
old policy in the 100-range. |
58 |
|
59 |
Remember the kdevtmpfs related patch I once suggested to the eclass? |
60 |
[1] Its horrible code, and this one didn't have to deal with "just |
61 |
doing this once". |
62 |
|
63 |
[1] https://archives.gentoo.org/gentoo-hardened/message/08b8c81d79720857045d762bb8cdbf62 |
64 |
|
65 |
I think we should put our focus elsewhere. Module priorities are nice, |
66 |
but are not the innovative solution that our users are waiting for. |
67 |
|
68 |
Unlike some of the CIL promises that we still need to see land ;-) |
69 |
|
70 |
Wkr, |
71 |
Sven Vermeulen |