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.)