Re: [Qemu-devel] [PULL 04/05] seccomp: add setuid, setgid, chroot and setgroups to whitelist

[Namsun Ch'o <namnamc@airmail.cc>]

> I think this patch should not be applied, because it completely defeats
> the purpose of the sandbox.  With these syscalls whitelisted, -runas 
> and
> -chroot have absolutely no effect against an attacker, even with
> -sandbox on.
> 
> Paolo

Adding chroot() and set*id() doesn't break the purpose of the sandbox 
though,
because the only purpose of seccomp is to reduce kernel attack surface 
area.
Just because setuid() is permitted does not mean it can get root (and 
even if
it did, it would not escape the sandbox and be permitted to use denied
syscalls). The sandbox will be enforced no matter what your EUID.

The whitelist only means those calls are permitted, not that they will 
always
succeed without permission checks. If allowing them defeats the purpose 
of
-runas and -chroot, then both of those options would be useless without 
a
sandbox anyway. The only time I can think of where it wouldn't stop an
attacker is if you do -runas root with -chroot (which is silly because 
not
only does -runas root not work even if you are root, and root can break 
out of
a chroot anyway). Furthermore, if an attacker manages to find a kernel 
exploit
which gives them root anyway, they would do so without calling setuid() 
at
all. Which again shows that the purpose of the seccomp sandbox is to 
prevent
the kernel from being compromised, not to prevent a non-root process 
from
breaking out of a chroot or using setuid(0). That's what standard 
permission
checks are for, which a syscall whitelist does not replace or disable.

> Also, Namsun's emails are bouncing back. Don't know if it's worth to
> merge them with no valid author's contact.

My old email service had a hardware failure. I don't know when it'll be 
up.