On Tue, Mar 30, 2021 at 03:53:37PM -0700, Casey Schaufler wrote: > If you need to run legitimate SETUID (or file capability enabled) binaries > you can't use NO_NEW_PRIVS. You can use CAP_SYS_CHROOT, because capabilities > where designed to work with the UID mechanisms. All the discussion of "designing a system" around the isolation is missing the point here: this is designed so that no system owner coordination is needed. An arbitrary process can set no_new_privs and then confine itself in a chroot. There is no need for extra privileges, etc, etc. There shouldn't be a need for a privileged environment to exist just to let a process confine itself. This is why seccomp is generally so useful, and why Landlock is important: no coordination with the system owner is needed to shed attack surface. > In any case, if you can get other people to endorse your change I'm not > all that opposed to it. I think it's gratuitous. It irks me that you're > unwilling to use the facilities that are available, and instead want to > complicate the security mechanisms and policy further. But, that hasn't > seemed to stop anyone before. There's a difference between "designing a system" and "designing a process". No privileges are needed to use seccomp, for example. The only part of this design that worries me is that it seems as though it's still possible to escape the chroot if a process didn't set up its fds carefully, as Jann discussed earlier: https://lore.kernel.org/lkml/c7fbf088-02c2-6cac-f353-14bff23d6864@xxxxxxxxxxx/ Regardless, I still endorse this change because it doesn't make things _worse_, since without this, a compromised process wouldn't need ANY tricks to escape a chroot because it wouldn't be in one. :) It'd be nice if there were some way to make future openat() calls be unable to resolve outside the chroot, but I view that as an enhancement. But, as it stands, I think this makes sense and I stand by my Reviewed-by tag. If Al is too busy to take it, and James would rather not take VFS, perhaps akpm would carry it? That's where other similar VFS security work has landed. -- Kees Cook
