On May 11, 2019 7:43:44 PM GMT+02:00, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: >On Sat, May 11, 2019 at 1:31 PM Aleksa Sarai <cyphar@xxxxxxxxxx> 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". > > 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
