Thread (4 messages) 4 messages, 3 authors, 2016-10-19

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

From: Andy Lutomirski <luto@amacapital.net>
Date: 2016-10-19 18:36:30
Also in: linux-fsdevel

On Oct 19, 2016 9:54 AM, "Eric W. Biederman" [off-list ref] wrote:
Andy Lutomirski [off-list ref] writes:
quoted
On Tue, Oct 18, 2016 at 2:15 PM, Eric W. Biederman
[off-list ref] wrote:
quoted
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...
quoted
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.)
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help