Re: [gentoo-hardened] RFC: Improving support for (re)labeling packages when SELinux dependency is added

[Marc Schiffbauer]

* Sven Vermeulen schrieb am 21.08.14 um 20:13 Uhr:
>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 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.
>
>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 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?

It may be more likely that user have app-portage/portage-utils 
installed and the package is much smaller (6.4M vs 130k). Apart from 
that, qdepends is *much* faster:

pkg_postinst() {
  # Find all packages with this package in their RDEPEND
  PKGSET=$(qdepends -rCQ ${CATEGORY}/${PN})
  for PKG in ${PKGSET};
  do
    rlpkg ${PKG};
  done
}

anyway, a DEPEND on app-portage/portage-utils should not hurt too 
much (IMO).

-Marc


-- 
0x35A64134 - 8AAC 5F46 83B4 DB70 8317
             3723 296C 6CCA 35A6 4134