On Sat, Nov 15, 2014 at 10:40:06PM -0500, Theodore Ts'o wrote: > On Sat, Nov 15, 2014 at 06:35:05PM -0800, Josh Triplett wrote: > > >So arbitrarily anyone to drop groups from their supplemental group > > >list will result in a change from both existing practice and legacy > > >Unix systems, and it could potentially lead to a security exposure. > > > > As Andy pointed out, you can already do that with a user namespace, > > for any case not involving a setuid or setgid (or otherwise > > privilege-gaining) program. And requiring no_new_privs handles > > that. > > Well, it's no worse than what we can do already with the user > namespace, yes. I'm still worried it's going to come as a surprise > for some configurations because it's a change from what was allowed > historically. Then again, pretty much all of the tripwire and rootkit > scanners won't notice a "setuid" program that uses capabilities > instead of the traditional setuid bit, and most sysadmins won't think > to check for an executable with a forced capability mask, so this > isn't exactly a new problem.... We certainly have introduced orthogonal APIs in various areas before, such that applications written prior to those APIs may interact interestingly with them; we don't allow *breaking* those applications, or introducing security holes, but the existence of applications designed to block one particular way to do something doesn't *automatically* rule out the possibility of adding another way to do it. It does require some careful thought, though. When we introduced seccomp filters for syscalls, we tied them to no_new_privs to prevent any possible security holes caused by selective syscall denial/filtration. In this case, I'm indifferent about whether unprivileged setgroups works without no_new_privs; if people are comfortable with that, fine, and if people would prefer no_new_privs (or for that matter a sysctl, a compile-time option, or any other means of making the behavior optional), I can do that too. The security model of "having a group gives you less privilege than not having it" seems crazy, but nonetheless I can see a couple of easy ways that we can avoid breaking that pattern, no_new_privs being one of them. I'd like to make sure that nobody sees any other real-world corner case that unprivileged setgroups would break. - Josh Triplett -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
