Re: [REVIEW][PATCH] exec: Don't exec files the userns root can not read.

[Andy Lutomirski <luto@amacapital.net>]

[-- Attachment #1: Type: text/plain, Size: 1582 bytes --]

On Oct 19, 2016 9:54 AM, "Eric W. Biederman" <ebiederm@xmission.com> wrote:
>
> Andy Lutomirski <luto@amacapital.net> writes:
>
> > On Tue, Oct 18, 2016 at 2:15 PM, Eric W. Biederman
> > <ebiederm@xmission.com> 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.)

[-- Attachment #2: Type: text/html, Size: 2230 bytes --]