Block writes to /proc/self/exe and /proc/self/map_files

[giuseppe]

No description provided.

[brauner]

But you can't write to /proc/self/exe while there binary is executing. Iirc, the gist/a version of the CVE was that an O_PATH FD was opened and then it waited until the binary exited to overwrite it so that on the next exec it would be compromised. That won't be blocked by further restrictions. Maybe I misunderstand.

[giuseppe]

yes, sure you can't write while the binary is executing as you get EBUSY but it is still possible with a few more steps to overwrite it. I can rephrase that and describe better the root issue.

My attempt at solving it was rejected (https://lkml.indiana.edu/2301.3/00152.html) a couple of years ago, but still there is no solution to the issue, requiring the same workaround in multiple runtimes. Would it make things clearer to add a link to the previous proposed solution?

[giuseppe]

I've updated the description

[giuseppe]

@brauner @poettering any interest in this kernel feature?

[brauner]

Short of making the binary disappear it's almost impossible to fix this without quite a few heavy kernel changes. For example, by recording that a binary was opened via O_PATH when it was executing and then preventing reopening the binary writable afterwards. That is a giant amount of code and subtlety for something that's sufficiently worked around in userspace and only really affect privileged containers.

And making the "exe" link disappear - even opt-in - is a userspace compat break. So it's not that I don't acknowledge the problem I'm just not yet convinced that it's worth the added complexity.

If we had the upgrade work (I know, I'm a parrot) that makes O_PATH reopening restrictable then we could probably make this work smh (TM) but the motivation for this work can't be as small as that odd bug.

[giuseppe]

could it be restricted (through a prctl or any other mechanism) so that only processes that have CAP_SYS_PTRACE can access it? That is the same requirement that exists for /proc/self/map_files, so it wouldn't break CRIU. Sort of an extension to PR_SET_DUMPABLE, maybe could even be an extension to it.