Re: [PATCH] polystrap-binfmt for preparing the build host
On Thu, Jun 30, 2011 at 03:09:16PM +0200, Johannes Schauer wrote:
> Hi,
>
> On Wed, Jun 29, 2011 at 10:46:57PM +0200, Yann Dirson wrote:
> > * working on arm and armel targets on the same host
> > * targetting squeeze and wheezy on the same host
> > * developpers with no root access to the build host
> > * experimenting with changes to the -L tree used qemu, without
> > simultaneously breaking builds
> >
> > To put it short, /etc/qemu-binfmt/* solve a per-user problem in a
> > system-wide manner. This is bad in itself.
> An idea of mine to solve all those issues is, if qemu-user-static would
> interpret an environment variable containing the elf interpreter prefix
> that is normally given with -L.
>
> I opened a wishlist bug for qemu here:
>
> If this is implemented in qemu, one would do something like this:
>
> export QEMU_LD_PREFIX=/tmp/debian-sid-armel/
> fakeroot fakechroot chroot /tmp/debian-sid-armel/ dpkg --configure -a
>
> and by that one would no longer need /etc/qemu-binfmt/, would also
> always have the fitting shared libraries for each built, would need no
> root access to the build host and so on - probably targets all the
> issues you have correctly listed above.
>
> what do you think?
That's more or less the same idea, and as I said the security issues
must be well thought out:
> Instead of having qemu-*-static directly called by binfmt, we could
> call a wrapper script. That wrapper would be able to pass the -L flag
> to qemu, depending on caller's choice, eg. through the use of an
> envvar. If no envvar was set, then it could fall back to the
> system-default tree if any.
>
> What annoys me in this approach, are the possible security
> implications of letting a user influence running binaries. I suspect
> this could be applied to attack the system via setuid foreign
> binaries. The user mechanism should at least be ignored in that case,
> much like LD_* envvars in the same case.
That is, the binfmt declarations for qemu-static have "flags: OC",
which means it will honor setuid binaries...
Reply to: