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
