| Linux lets you create a namespace with no capability grants in it. That's what I said in my top post here. Linux lets you do it, sudo will even work it (and grant no real global capabilities) yet somehow it's a problem FOR LINUX that Linux has a userland process called sudo that couldn't ever work on Plan9. > You don't have the ability to change what the program doing authentication sees. Obviously not. It has to behave just like sudo in this regard! It's the only option! Since you can't do that, your rebindings are just as localized as what Linux permits. > Processes aren't allowed to become privileged without obtaining a cryptographic capability token via negotiation with the authentication agent. The auth agent which was started at boot will write the secret to the kernel, and give you the hash of it so you can prove you are the rightful recipient of that uid switch request. If you don't have the right secrets, you don't get a token. This is pretty cool, and also something that could be put into a Linux userspace daemon to authenticate privileged operations. I mean this is all userspace details from a Linux perspective. Systemd could do this or some PAM module. > Removing suid binaries with config files as a method for privilege escalation is the right path. They don't play well with namespaces. Suid binaries aren't used that commonly for privilege escalation anyway. Much more ordinary is to use privilege inherited from init. |
Again, going back to the example I was using: How does that help with securely allowing `$get_permissions debug-my-kernel`?
Sudo is a HOLE IN THE SIDE OF A BOAT. It is not a problem for Plan 9, because plan 9 does not have a hole, and is therefore not doing contortions to avoid filling with water. Designing a boat without a hole in its side is generally considered a good idea. Designing a security model without a suid in its side is a similarly good idea.
If you want `auth/as`, it's there. But it does not use suid, and therefore does not have the problems created by suid.