From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: MIME-Version: 1.0 In-Reply-To: <87y41kjn6l.fsf@xmission.com> References: <87twcbq696.fsf@x220.int.ebiederm.org> <20161018135031.GB13117@dhcp22.suse.cz> <8737jt903u.fsf@xmission.com> <20161018150507.GP14666@pc.thejh.net> <87twc9656s.fsf@xmission.com> <20161018191206.GA1210@laptop.thejh.net> <87r37dnz74.fsf@xmission.com> <87k2d5nytz.fsf_-_@xmission.com> <87y41kjn6l.fsf@xmission.com> From: Andy Lutomirski Date: Wed, 19 Oct 2016 11:36:30 -0700 Message-ID: Subject: Re: [REVIEW][PATCH] exec: Don't exec files the userns root can not read. To: "Eric W. Biederman" Cc: Michal Hocko , Oleg Nesterov , Linux FS Devel , "linux-mm@kvack.org" , Linux Containers , "linux-kernel@vger.kernel.org" , Jann Horn Content-Type: multipart/alternative; boundary=001a114e5a44a94c3e053f3c170e Sender: owner-linux-mm@kvack.org List-ID: --001a114e5a44a94c3e053f3c170e Content-Type: text/plain; charset=UTF-8 On Oct 19, 2016 9:54 AM, "Eric W. Biederman" wrote: > > Andy Lutomirski writes: > > > On Tue, Oct 18, 2016 at 2:15 PM, Eric W. Biederman > > 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.) --001a114e5a44a94c3e053f3c170e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Oct 19, 2016 9:54 AM, "Eric W. Biederman" <<= a href=3D"mailto:ebiederm@xmission.com" target=3D"_blank">ebiederm@xmission= .com> wrote:
>
> Andy Lutomirski <luto@amacapital.net> writes:
>
> > On Tue, Oct 18, 2016 at 2:15 PM, Eric W. Biederman
> > <eb= iederm@xmission.com> wrote:
> >>
> >> When the user namespace support was merged the need to preven= t
> >> 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 suppo= rt
> added that I am closing.=C2=A0 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.=C2=A0 A program that real= ly wants
> > to be unreadable should have a stub: the stub is setuid and reada= ble,
> > 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 pro= gram'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.=C2= =A0 It was probably my first kernel patch ever and it fixed an awkward-to-e= xploit race.=C2=A0 But it's been a while.)

--001a114e5a44a94c3e053f3c170e-- -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org