A local root vulnerability in glibc [LWN.net]

A local root vulnerability in glibc

Posted Oct 5, 2023 12:36 UTC (Thu) by hmh (subscriber, #3838)
In reply to: A local root vulnerability in glibc by NYKevin
Parent article: A local root vulnerability in glibc

As if the polkit and friends security surface is any smaller and more defended than glibc's complicated mess of a dynamic loader. Security issues are not unknown in that space, either. And it is way too complicated, even harder to use correctly than suid/sgid.

The correct answer here is more likely to be in he direction of: keep suid and sgid around and use it where possible while nothing better and safer like capabilities are available for what you need. But do that while actually hardening for real the dynamic linker without weakening security for any reason. No debugging, no behaviour modification based on the environment.

Then, one would need a separate, object-build-time thing for debugging suid/sgid binaries that cannot be in any way shoehorned into a production suid or sgid binary, instead. More annoying to developers, but that much safer for everyone.

to post comments

A local root vulnerability in glibc

Posted Oct 5, 2023 18:15 UTC (Thu) by NYKevin (subscriber, #129325) [Link]

Well, IMHO the *real* real option is just "don't elevate your privileges at all." If you want something to happen at a higher security level, you configure systemd to do it when you're building the image. Then you don't need to do any runtime checks at all, and nothing from a lower privilege level ever asks a higher privilege level to do anything.

But people don't like it when I tell them that (presumably because they don't like containers and/or VMs), so I have to provide some kind of alternative. You're right that polkit is not ideal, but it is the project that actually exists in this space. If you can point me to a better one, I'll gladly start recommending that instead.

> But do that while actually hardening for real the dynamic linker without weakening security for any reason. No debugging, no behaviour modification based on the environment.

I consider this less than ideal for one very simple reason: Traditionally, the rule has been that the child process inherits the uid of its parent, and so it was assumed that the parent could not attack the child (they're both the same user). Many process parameters are therefore inherited over a fork/exec, and this is widely used in practice for process configuration. Shells, for instance, are heavily dependent on being able to reconfigure a child process between fork and exec. Setuid breaks this assumption, and creates a security boundary in a very inconvenient location, so you end up having to go through the entire list of process configuration variables and manually deny all the ones that are likely to cause problems. Security should be based on allowlisting, not denylisting, and so I consider it a fundamentally flawed approach.