On Fri, Jun 22, 2012 at 2:34 PM, Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote: > On Fri, 22 Jun 2012 14:09:28 -0700 > Kees Cook <keescook@xxxxxxxxxxxx> wrote: > >> On Fri, Jun 22, 2012 at 12:55 PM, Andrew Morton >> <akpm@xxxxxxxxxxxxxxxxxxxx> wrote: >> > On Fri, 22 Jun 2012 12:24:13 -0700 >> > Kees Cook <keescook@xxxxxxxxxxxx> wrote: >> > >> >> The value >> >> of suid_dumpable=2 is now historic, and attempting to set this sysctl >> >> value returns -EINVAL. >> > >> > This sounds a bit harsh - will it not cause existing configurations to >> > immediately break? __If so, would it not be better to retain the =2 mode >> > for a while, and emit a nice warning when it is set? >> >> I view it as a security vulnerability, so I'd rather see it >> eliminated. I see "=1" as a security vulnerability too, but at least >> that's well-known to be a bad idea. The "=2" mode has been assumed to >> be safe, but it isn't. > > But what will be the effects of the change? People's initscripts do an > "echo 2" which fails and the error message (if any) won't get logged > anywhere where anyone looks. So now their machine is bumbling along in > the wrong mode and much later on, someone notices that coredumps are > going awry? This is not exactly a user-friendly way of rolling out > kernel API changes! Well, this is why I wanted to just change the meaning of "2" instead of introducing "3". It seems much cleaner to me. Just stop "2" from doing the dangerous thing and carry on. > And how serious is the security vulnerability, in real-world terms? > Serious enough to risk this amount of bustage? If they're running in mode "2" and they do not have a coredump pipe handler defined, local users can gain root access. -Kees -- Kees Cook Chrome OS Security -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
