The trouble with symbolic links

Are you suggesting that if someone calls a suid binary inside a container, the binary should not use the mount namespace of the container but the root mount namespace instead?

That's exactly the point I was going to make. bind mounts in private namespaces are perfectly safe. setuid programs as profoundly broken, whether you use namespaces or not.
If we, collectively, were serious about security, we would be mounting all filesystems with nosuid.

One of the things I appreciate in Rust is that where there are special cases somebody takes the time to think about whether in fact there's some more general principle of which the special case was just the easy to observe part, the tip of the iceberg so to say, and to provide for the general principle, rather than just the special case.

Example: If you're a Rust beginner you learn that Option's None and Result's Error can be passed back up to your caller where appropriate with the '?' try operator and this seems like a special case, you can't go around treating an integer, or a file handle, or some other kind of thing this way. Or can you? In fact the general principle is the (nightly gated) Try trait, and Option and Result merely implement Try (they're allowed to do this even in stable Rust because Rust internally isn't subject to its own stability rules or it'd be recursively impossible to develop anything)

Another example: In languages with ad hoc polymorphism ("Function overloading") it's obvious that "LWN.net".contains("LWN") and "LWN.net".contains('.') are both reasonable things to write so you just overload the function to do either. Rust doesn't have ad hoc polymorphism, so it must decide what type that parameter is such that both "LWN" and '.' match or else provide two functions with different names. The resulting trait Pattern once again represents a more general principle - any pattern which could match parts of a string, and so in Rust you can also write "LWN.net".contains(char::is_alphabetic) because hey, char::is_alphabetic is a function which matches parts of a string so why not.

I think SUID just isn't one of those things, it's a profoundly special case, and so we should immediately be prejudiced against it as a design feature of the operating system. Rather than everything just falling out naturally, as we'd like for a general solution, SUID means everywhere we need to handle this differently. If you've just written a bunch of low level code there's a good chance that if I remind you that SUID exists you'll need to go back and add a bunch of conditional branches to handle that...

User namespaces are designed such that this is supposed to not be necessary: you can only mount things if you create a new user namespace, and if you are fully unprivileged, you can only map ns-root to your own or a delegated uid, so you cannot trick host root with bind mounts and a setuid-root binary. The problem with user namespaces comes because user namespaces also want to grant ns-root privilege over the resources owned by the creator. And they do that pretty well, it's just that that expands the amount of kernel code which an unprivileged user can exercise, and exploit.

> privilege escalation should occur via communication with a system daemon using a well-defined protocol

Several people have tried to the plumbing needed for plan-9 factotum functionality into the kernel. My last attempt (expanding on Ashwin Ganti's original code) was 10 years ago - https://lore.kernel.org/all/20100427164139.GA7359@us.ibm.... , and there was a more recent independent patch posted at https://lore.kernel.org/all/20180210165845.18852-1-metux@... .