On 8/25/25 11:26, Michael Tokarev wrote:
On 25.08.2025 11:42, Helge Deller wrote:
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.
It is not potential. It is right there, very much real, -- that's the
whole difference.
We've, for example, wireshark which is a big complex GUI app often
installed suid-root to be able to watch network traffic. There's also
a huge difference between wireshark and qemu, -- while wireshark is
complex and all, and sure has bugs, it *tries* to be as careful as
possible, and drops privs once network sockets are open, etc.
Qemu, on the other hand, has never been designed to be run in suid
mode, and does not perform even minimal input sanitizing, it blindly
follows what the user specified. Before suid mode can *ever* be
enabled, we should at least try some minimum to filter env. vars and
whatnot, so that it is not trivial to own whole system just by running
a foreign binary.
Until this is done, option to run it with suid binaries should not
exist.
BTW, I think we can do a bit better here when I thought.
qemu-linux-user can detect if it's running a suid binary, and if yes,
*and* if any option/environment is specified, just *refuse* to run
(or drop privs back to euid/egid), instead of trying to sanitize them.
With that, we can *try* to enable credentials flag with binfmt, with
a big fat warning.. maybe. At least we can think about the possibility.
But not before. I think.
...
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.
It doesn't matter how good or useful this flag is in qemu-user context.
Right now, qemu is not prepared to handle it in any sensible way. And
with that, it doesn't matter how important or useful these use cases
are: we just don't have what people want, it simply doesn't exist...
Maybe a better comparison is not having /bin/sh suid-root, but having
a *copy* of /bin/sh, say, /bin/suid-sh, which is suid-root. This is
what qemu-user currently is - it is not usual system interpreter, it
is an "alternative" system interpreter, ready to be used when "needed" -
by anyone, including any evil person.
This is not the beginning of this discussion, - first was similar
arguments on debian mailing lists, following the debian security
announce of qemu-user dropping the credentials flag. People also
started suggesting (or demanding) to have an option to return this
flag back on. No, this wont be done, this is not discussable - until
qemu has at least minimal input sanitizing, such mode simply does not
exist, so there's nothing to enable.
I'm really surprised, even shocked, why people don't understand such
simple things.
I'm pretty sure most people here understand this.
And, that you disabled it by default is absolutely right.
Keep it this way!
This saves everyone to run into a disaster by default.
But please keep in mind, that many machines are being used
solely by their owner. No remote login or such. Just being used for development.
And on such machines people may need to use qemu being able to
run suid programs.
By hiding/disabling this possibility you patronise those people and
prevent them from using a needed feature in their known & safe environment.
Helge
