On 8/24/25 13:54, Michael Tokarev wrote:
On 24.08.2025 13:59, Helge Deller wrote:
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 is not "someone can shoot himself into the foot".
We don't ship a configuration option to make /bin/sh suid root.
This would make a lot of use cases to work, this will simplify a lot
of stuff, etc. But we don't have such option. This is done for a
reason, - it breaks whole system security concept, entirely. You
can chmod u+s /bin/sh on any of your system, but this "configuration
item" is not even described in any official docs.
Unfortunately, qemu's C flag is of this same theme. It requires a
tiny effort to get root, compared with `chmod u+s /bin/sh`, but it's
a trivial way still, just one extra step. In short, qemu-user C flag
breaks whole system security concept.
I think we all are clear why there is a potential security issue.
This is why it not only shouldn't be on by default but it should not
exist, at all.
And here we disagree.
Based on your argument you should drop the "chmod" command
from debian as well. It's dangerous, so it shouldn't exist
at all! It shouldn't even be documented!
This is a wrong mindset IMHO.
I agree with disabling it by default.
I agree that it should print a fat warning too.
But you should keep it possible for those (few) users to enable
it if they need to use it. In the same manner, that "chmod" still
exists too.
And if some system is willing to do chmod u+s their /bin/sh, they're
free to do so, it's not a rocket science or requires a recompile or
something.
As you know, for those need Qemu's credential flag,
the "chmod u+s /bin/sh" generates many more implications than Qemu's flag,
so they would prefer the qemu credential flag.
Helge
