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

[Andy Lutomirski]

> On May 12, 2019, at 6:35 AM, Aleksa Sarai <cyphar@xxxxxxxxxx> wrote:
> 
>> On 2019-05-12, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
>>> On Sat, May 11, 2019 at 7:37 PM Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote:
>>> I bet this will break something that already exists. An execveat()
>>> flag to turn off /proc/self/exe would do the trick, though.
>> 
>> Thinking more about it, I suspect it is (once again) wrong to let the
>> thing that does the execve() control that bit.
>> 
>> Generally, the less we allow people to affect the lifetime and
>> environment of a suid executable, the better off we are.
>> 
>> But maybe we could limit /proc/*/exe to at least not honor suid'ness
>> of the target? Or does chrome/runc depend on that too?
> 
> Speaking on the runc side, we don't depend on this. It's possible
> someone depends on this for fexecve(3) -- but as mentioned before in
> newer kernels glibc uses execve(AT_EMPTY_PATH).

Why are we concerned about suid?  Donât we already block suid if the path being execed doesnât come from the current mountns?  That should mostly cover the things we care about, no?

I suppose we could also block suid for deleted files, so that deleting a known-buggy suid binary becomes more reliable. But every sensible package tool should already be chmoding the suid away before unlinking.