On 2019-05-11, Linus Torvalds <torva...@linux-foundation.org> wrote: > On Sat, May 11, 2019 at 1:31 PM Aleksa Sarai <cyp...@cyphar.com> wrote: > > Yup, I've dropped the patch for the next version. (To be honest, I'm not > > sure why I included any of the other flags -- the only one that would've > > 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".
*sheepishly* Actually we use this in runc very liberally. It's done because we need to run namespace-related code but runc is written in Go so (long story short) we re-exec ourselves in order to run some __attribute__((constructor)) code which sets up the namespaces and then lets the Go runtime boot. I suspect just writing everything in C would've been orders of magnitude simpler, but I wasn't around when that decision was made. :P Also as Christian mentioned, fexecve(3) in glibc is implemented using /proc/self/fd on old kernels (then again, if we change the behaviour on new kernels it won't matter because glibc uses execveat(AT_EMPTY_PATH) if it's available). -- Aleksa Sarai Senior Software Engineer (Containers) SUSE Linux GmbH <https://www.cyphar.com/>
signature.asc
Description: PGP signature
