On 24.08.2025 13:59, Helge Deller wrote:
On 8/24/25 12:16, Michael Tokarev wrote:
...
At the very least, I propose to remove --credential option from
scripts/qemu-binfmt-setup.sh entirely (patch will follow) - not to
help someone to shoot themselves in the foot.
I really disagree on this.
There are very good reasons to have qemu with credentials enabled.
One such valid example is to used debian as buildd server to cross-compile
debian packages for other architectures. For this you need to have
credentials enabled for quite some packages, so with security in mind
you should normally not allow other users to access the machine.
Umgh no. It does not matter how good or important any existing (or
future) usages of this thing are. We have something which is not
designed to be used this way, and we don't provide ways to use it
like that.
There's nothing stops any user from enabling these flags. Consider
lack of direct instructions to be a clue barrier - if you figured out
how to enable execution of foreign suid binaries, one might assume
you've understood the implications.
I know debian buildds and their issues with this context. It is a very
niche thing and there, again, it is trivial to change the entry provided
by qemu to include additional flags (it's a one-line config file).
And even there, - the buildds - I tend to disagree in general with the
whole approach. Instead of letting suid-to-root in debian CI tests,
it is better to rewrite tests which do use it (using sudo usually) to
avoid such access entirely. After all, initial CI script can be told
to be run as root (and build can be done as root too), and it can always
perform su from root to a less-privileged user, not requiring the
opposite way.
Right now we can't do that, but having found this issue, it's not a big
deal to file bugs against packages in debian who do it, and fix them.
After which, C flag wont be required in debian buildds.
In general, just if someone can shoot himself into the foot you should
not remove features.
Instead, disabling it by default, and adding a big fat warning if people
enable it is a good way forward.
It should not be noted in any docs or examples either (how to
configure it to work with suid foreign binaries, that is).
Disagree. Hiding issues don't solve them.
It is not hiding, not at all. On the contrary, I suggested adding a
warning *not* to enable this to the docs, and why. Not provide
instructions of what should not be done, but provide reasons of why
it shouldn't be done. This is definitely not hiding.
Instead, we can add a big fat warning in the docs which tells the
user *not* to try doing that.
Yes. Agreed.
Thanks,
/mjt
