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.
