On Thu, Aug 21, 2014 at 06:13:01PM +0000, Sven Vermeulen wrote:
> During a discussion about dependencies and SELinux labeling, I noticed that
> we might want to improve how we currently handle pure policy-related
> dependencies.
>
> What we want to get at, is that the installation of a SELinux policy package
> results in the (re)labeling of the files of the packages it holds policy
> data (well, file contexts to be exact) of.
>
> What we currently do is a subset of that: when a package is installed, its
> associated SELinux policy package is merged before the package itself, so
> that Portage can correctly label the files of the package. This means both a
> DEPEND (has to be installed before the package) and RDEPEND (because of
> binary packages) is used.
>
> This doesn't implement what we really need fully though: updates on the
> SELinux policy do not reflect upon the labels of the packages if they are
> already installed. For instance, if we would change the label of the
> "emerge" command in the policy, then this label is not applied unless the
> administrator rebuilds Portage, relabels Portage or relabels the file
> system.
This is currently a fairly important issue, I end up just manually running
"restorecon -r /" a lot to update labels after things are fixed in the
policy which should not be required.
What comes up a lot is someone installs a new version of a program and
then sees it needs some different selinux rules which would then take a
wihle to get down to stable but by then all users are on the new version
so as it is now would not get the new labels.
> This also means that we currently abuse the Portage dependency system to
> accomplish a reasonable implementation. So... why not see how we can fix
> things?
>
> It would be nice if we could only mark the dependencies are RDEPEND, and in
> the policy installation phase (its pkg_postinst() method) find out what
> package(s) are RDEPEND'ing on this package, and then relabel the files of
> those packages.
I would ideally like the deps to go the other way since I think they are
more like the policy "provides" things for those packages, not that
those packages "depend" on the policy. But as I am not aware of a way to
express this in portage, RDEPEND is fine.
> Something like so (which we can do in the selinux-policy-2.eclass):
>
> pkg_postinst() {
> # Find all packages with this package in their RDEPEND
> PKGSET=$(equery -q depends ${CATEGORY}/${PN})
> for PKG in ${PKGSET};
> do
> rlpkg ${PKG};
> done
> }
This looks like it would work apart from the optional equery. What about
if the user does not want something relabelled after updating if they
have special circumstances? We might want a way to say don't touch this
package I'll do it myself. Alternatively the user would just have to set
it in semange fcontext and it'll be fine.
-- Jason
> This simple implementation would allow us to only use RDEPEND, and would
> also relabel the files after a policy update (which we don't do now) and
> also doesn't require any changes to Portage or EAPI or whatever and does not
> trigger any unnecessary rebuilds...
>
> ... but (there is always a but) uses a currently optional tool (equery)
> which is probably also quite slow for some users. Still, I do like this
> idea as it is very simple. And I like simple. Simple is nice.
>
> Anyone know of a way to do something similar without depending on equery (it
> doesn't seem like portageq has the necessary features for this)?
>
> Anyone know of a better approach?
>
> Wkr,
> Sven Vermeulen
>
