On Oct 19, 2016 9:54 AM, "Eric W. Biederman" <ebiederm@xxxxxxxxxxxx> wrote: > > 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. > But if it was never secure in the first place... > > 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. I thought it killed the setuid, not the ptrace. (I ought to know because I rewrote that code back in 2005 or so back when I thought kernel programming was only for the cool kids. It was probably my first kernel patch ever and it fixed an awkward-to-exploit race. But it's been a while.) _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/containers
