1 |
On Thu, Aug 21, 2014 at 06:13:01PM +0000, Sven Vermeulen wrote: |
2 |
> During a discussion about dependencies and SELinux labeling, I noticed that |
3 |
> we might want to improve how we currently handle pure policy-related |
4 |
> dependencies. |
5 |
> |
6 |
> What we want to get at, is that the installation of a SELinux policy package |
7 |
> results in the (re)labeling of the files of the packages it holds policy |
8 |
> data (well, file contexts to be exact) of. |
9 |
> |
10 |
> What we currently do is a subset of that: when a package is installed, its |
11 |
> associated SELinux policy package is merged before the package itself, so |
12 |
> that Portage can correctly label the files of the package. This means both a |
13 |
> DEPEND (has to be installed before the package) and RDEPEND (because of |
14 |
> binary packages) is used. |
15 |
> |
16 |
> This doesn't implement what we really need fully though: updates on the |
17 |
> SELinux policy do not reflect upon the labels of the packages if they are |
18 |
> already installed. For instance, if we would change the label of the |
19 |
> "emerge" command in the policy, then this label is not applied unless the |
20 |
> administrator rebuilds Portage, relabels Portage or relabels the file |
21 |
> system. |
22 |
|
23 |
This is currently a fairly important issue, I end up just manually running |
24 |
"restorecon -r /" a lot to update labels after things are fixed in the |
25 |
policy which should not be required. |
26 |
|
27 |
What comes up a lot is someone installs a new version of a program and |
28 |
then sees it needs some different selinux rules which would then take a |
29 |
wihle to get down to stable but by then all users are on the new version |
30 |
so as it is now would not get the new labels. |
31 |
|
32 |
> This also means that we currently abuse the Portage dependency system to |
33 |
> accomplish a reasonable implementation. So... why not see how we can fix |
34 |
> things? |
35 |
> |
36 |
> It would be nice if we could only mark the dependencies are RDEPEND, and in |
37 |
> the policy installation phase (its pkg_postinst() method) find out what |
38 |
> package(s) are RDEPEND'ing on this package, and then relabel the files of |
39 |
> those packages. |
40 |
|
41 |
I would ideally like the deps to go the other way since I think they are |
42 |
more like the policy "provides" things for those packages, not that |
43 |
those packages "depend" on the policy. But as I am not aware of a way to |
44 |
express this in portage, RDEPEND is fine. |
45 |
|
46 |
> Something like so (which we can do in the selinux-policy-2.eclass): |
47 |
> |
48 |
> pkg_postinst() { |
49 |
> # Find all packages with this package in their RDEPEND |
50 |
> PKGSET=$(equery -q depends ${CATEGORY}/${PN}) |
51 |
> for PKG in ${PKGSET}; |
52 |
> do |
53 |
> rlpkg ${PKG}; |
54 |
> done |
55 |
> } |
56 |
|
57 |
This looks like it would work apart from the optional equery. What about |
58 |
if the user does not want something relabelled after updating if they |
59 |
have special circumstances? We might want a way to say don't touch this |
60 |
package I'll do it myself. Alternatively the user would just have to set |
61 |
it in semange fcontext and it'll be fine. |
62 |
|
63 |
-- Jason |
64 |
|
65 |
> This simple implementation would allow us to only use RDEPEND, and would |
66 |
> also relabel the files after a policy update (which we don't do now) and |
67 |
> also doesn't require any changes to Portage or EAPI or whatever and does not |
68 |
> trigger any unnecessary rebuilds... |
69 |
> |
70 |
> ... but (there is always a but) uses a currently optional tool (equery) |
71 |
> which is probably also quite slow for some users. Still, I do like this |
72 |
> idea as it is very simple. And I like simple. Simple is nice. |
73 |
> |
74 |
> Anyone know of a way to do something similar without depending on equery (it |
75 |
> doesn't seem like portageq has the necessary features for this)? |
76 |
> |
77 |
> Anyone know of a better approach? |
78 |
> |
79 |
> Wkr, |
80 |
> Sven Vermeulen |
81 |
> |