Re: qemu-user viability (was Re: [SECURITY] [DSA 5983-1] qemu security update)
On Sat, 2025-08-23 at 16:19 +0200, Thorsten Glaser wrote:
> (Cc porters, for the arches where some buildds use qemu-user)
Removing debian-ports@lists.debian.org again and using debian-68k@lists.debian.org
and debian-superh@lists.debian.org instead as to not spam all ports mailing lists.
> On Sat, 23 Aug 2025, Michael Tokarev wrote:
>
> > > Does this entirely break things like running sudo within a
> > > qemu-user-emulated chroot (or buildd/cowbuilder/schroot)?
>
> > It discontinues elevating (changing) privileges using qemu-user binfmt
> > handler. Things like /foreign/chroot//bin/su and /foreign/chroot/bin/sudo
> > does not work anymore. If you run sudo /foreign/chroot/bin/bash,
> > your bash will continue run as root under qemu-user, as before.
>
> But the use case is:
>
> prompt> chroot /foreign/chroot su - user
> chroot> do something
> chroot> sudo do something else # this step
> […]
> chroot> exit
>
> This needs to work, or at least be enablable (with a documentation
> in at least README.Debian, with a NEWS.Debian entry pointing to it
> saying precisely how, not vague “this will require changes to your
> deployment”).
>
> > There are no alternatives - qemu is unique in this regard. And
> > it has never been designed for this usage. What we had for 15+
> > years, unnoticed, is like `chmod u+s /bin/sh`, which is never
> > supposed to be used like this.
>
> Perhaps, but there’s shades in between.
>
> > If you rely on suid/sgid *foreign* binaries, that's where the
> > problem lies.
>
> Yes. People expect to be able to run foreign-arch chroots.
> Entire buildd setups partly rely on this, too…
I don't know if this change breaks sbuild with qemu-user or not, but if
it does, I will just switch back to custom builds of qemu-user again which
Michael won't possibly like but if it's inevitable there is nothing I can
do.
> > I'm sorry if you disappointed you, but here's how things work.
>
> That is a bad cop-out.
>
> > As stated in the announcement, if you relied on this feature,
> > you have to rework your setup.
>
> And that is both too vague and not in README.Debian so that
> people installing qemu-user later can find that.
The description of the bug and the necessary changes are also way too
vague. It just says "this will require changes to your deployment"
which is completely useless.
If it requires changes to the deployment, please tell me which changes.
Also, it seems that Debian decided on it's own to implement this change
as there doesn't seem to be any official CVE entry for that unless I am
missing something.
Either way, packagers should always keep in mind that software is supposed
to serve the needs of your end users and not a university's thesis or anything
else theoretical.
Hopefully Michael can further explain these changes and also demonstrate
that these changes don't break sbuild with qemu-user. Since cross-building
with sbuild with the help of qemu-user is officially supported, this feature
shouldn't break because of some obscure theoretical scenario that a security
researcher came up with.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Reply to: