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

On May 12, 2019, at 6:35 AM, Aleksa Sarai [off-list ref] wrote:

quoted

On 2019-05-12, Linus Torvalds [off-list ref] wrote:

quoted

On Sat, May 11, 2019 at 7:37 PM Andy Lutomirski [off-list ref] 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.