Andy Lutomirski <luto@xxxxxxxxxxxxxx> writes: > On Tue, Oct 18, 2016 at 2:15 PM, Eric W. Biederman > <ebiederm@xxxxxxxxxxxx> wrote: >> >> When the user namespace support was merged the need to prevent >> ptracing an executable that is not readable was overlooked. > > Before getting too excited about this fix, isn't there a much bigger > hole that's been there forever? In this case it was a newish hole (2011) that the user namespace support added that I am closing. I am not super excited but I figure it is useful to make the kernel semantics at least as secure as they were before. > Simply ptrace yourself, exec the > program, and then dump the program out. A program that really wants > to be unreadable should have a stub: the stub is setuid and readable, > but all the stub does is to exec the real program, and the real > program should have mode 0500 or similar. > > ISTM the "right" check would be to enforce that the program's new > creds can read the program, but that will break backwards > compatibility. Last I looked I had the impression that exec of a setuid program kills the ptrace. If we are talking about a exec of a simple unreadable executable (aka something that sets undumpable but is not setuid or setgid). Then I agree it should break the ptrace as well and since those programs are as rare as hens teeth I don't see any problem with changing the ptrace behavior in that case. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
