A local root vulnerability in glibc

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.