Thread (25 messages) 25 messages, 7 authors, 2019-05-11

Re: [PATCH v6 5/6] binfmt_*: scope path resolution of interpreters

From: Christian Brauner <christian@brauner.io>
Date: 2019-05-11 17:49:05
Also in: linux-arch, linux-fsdevel, lkml

On May 11, 2019 7:43:44 PM GMT+02:00, Linus Torvalds [off-list ref] wrote:
On Sat, May 11, 2019 at 1:31 PM Aleksa Sarai [off-list ref] wrote:
quoted
Yup, I've dropped the patch for the next version. (To be honest, I'm
not
quoted
sure why I included any of the other flags -- the only one that
would've
quoted
been necessary to deal with CVE-2019-5736 was AT_NO_MAGICLINKS.)
I do wonder if we could try to just set AT_NO_MAGICLINKS
unconditionally for execve() (and certainly for the suid case).

I'd rather try to do these things across the board, than have "suid
binaries are treated specially" if at all possible.

The main use case for having /proc/<pid>/exe thing is for finding open
file descriptors, and for 'ps' kind of use, or to find the startup
directory when people don't populate the execve() environment fully
(ie "readlink(/proc/self/exe)" is afaik pretty common.

Sadly, googling for

   execve /proc/self/exe

does actually find hits, including one that implies that chrome does
exactly that.  So it might not be possible.

Somewhat odd, but it does just confirm the whole "users will at some
point do everything in their power to use every odd special case,
intended or not".

                 Linus
Sadly I have to admit that we are using this.
Also, execveat on glibc is implemented via
/proc/self/fd/<nr> on kernels that do not
have a proper execveat.
See fexecve...

Christian
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help