Message ID | 20240712-vfs-procfs-ce7e6c7cf26b@brauner (mailing list archive) |
---|---|
State | New |
Headers | show |
Series | [GIT,PULL,for,v6.11] vfs procfs | expand |
> years various exploits started abusing /proc/<pid>/mem (cf. [1] and [2]). > Specifically [2] is interesting as it installed an arbitrary payload from Sorry, the two links were missing: [1]: https://lwn.net/Articles/476947 [2]: https://issues.chromium.org/issues/40089045
On Fri, 12 Jul 2024 at 06:59, Christian Brauner <brauner@kernel.org> wrote: > > The level of fine-grained management isn't my favorite as it requires > distributions to have some level of knowledge around the implications of > FOLL_FORCE and /proc/<pid>/mem access in general. Ugh. I pulled this, and looked at it, and then I decided I can't live with something this ugly. First off, there is ABSOLUTELY no reason for any of this to be using static keys, which makes an already ugly patch even uglier. None of this is magically so performance-critical that we'd need static keys for this kind of thing Secondly, this is absolutely the wrong kind of nairy rat's nest of strange conditionals made worse by pointlessly adding kernel command line options for it. Now, the FOLL_FORCE is unquestionably problematic. But this horror isn't making it better - it's just obfuscating a bad situation and making it worse. By all means just add one single kernel config option to say "no FOLL_FORCE in /proc/pid/mem". Or require it to *actually* be traced, or something like that. But not this horror. Linus
> But not this horror.
I agree and I didn't like it much myself (as evident from my pr message).