Re: qemu-user security trade-offs by dynamic configuration
On 24.08.2025 01:00, John Scott wrote:
Hello,
Hi!
...an option that I haven't seen mentioned: how about using a low-priority (i.e. not shown by default) Debconf question to allow configuring the old behavior?
No. Just like with suid-root /bin/sh (or suid-root /bin/tee), there must
not be such option - not only in debconf, but in any readme files or any
other documentation.
qemu-user in its current way is not supposed to work in this mode.
In order to avoid complete system compromise through qemu-user, C flag,
and any foreign suid binary, you have to - very carefully - ensure that
such foreign suid-binary is not accessible to any user on the system.
Once any user has access to such binary, there are trivial steps to
have root. Only the code which you trust can be run in this mode.
I believe this is an approach used by some network diagnostic tools in Debian (Wireshark and friends perhaps?). For example a tool that's rarely used and is only manually invoked by an experienced sysadmin might not have a compelling need for a set-UID bit or e.g. CAP_NET_RAW set, but for other respectable use cases such as automation, or when other security enhancements are in place, or on systems that are not mission-critical, an administrator/user may decide incurring a risk is acceptable or advances "the greater good".
wireshark is a complex software, yet it is written with being able to
run suid-root in mind, and whole thing was written very carefully.
We can't guarantee no bugs in all the (GUI and other) libraries it
uses, this is why it has an option to make it suid or not.
With qemu, it has NO security control watsoever, it has never been
written in contest of it being run in suid(root,whatever) environment.
The user completely controls which code qemu runs, and with C flag,
this code is run as root.
So it is completely different situation compared with wireshark, or
maybe gdisk (iirc, -- the gui util to partition your drive), and the
likes, - who was written with suid context in mind from the very
beginning.
I repeat.
If someone really wants the old behavior, it is trivial to restore
by using custom binfmt entry with the C flag. But it must not be
done not only in debconf but in docs/readmes too. And if want
adventures, you will find this (simple) way. Just like you can
chmod u+s /bin/sh using dpkg-statoverride.
Somehow it feels like people can't grok the severity of this issue.
For the start, run (as non-root):
QEMU_LOG_FILENAME=/etc/shadoww /foreign/chroot/bin/su
and hit Ctrl+C. And see /etc/shadoww gets created. After update,
it wont be created anymore. And this usage of environment vars
is just a tip of the iceberg. Whole qemu code is written in a way
which is not supposed to run anything security-sensitive.
Thanks,
/mjt
Reply to: