[ori_b]

> But in Plan9 there's no setuid binary at all yet it's not a problem?

I think you mean, 'and therefore, it's not a problem.'

In plan 9, the program that allows you to switch users needs almost no privileges.

> Plan9 has no better way than that, no way to make /bin rebinding work in a way that makes sense for privilege escalation.

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.

You can't swap the devcap in the authenticators namespace, and negotiating with a rebound devcap is simply not going to work, because your authentication token wasn't written into it. You don't have the ability to change what the program doing authentication sees.

In summary: There's no information attached to the binary, and no capability grants in a namespace you can rebind.

If you want to namespace this sort of authentication agent, it's also possible -- you can authenticate, escalate permissions, and start your own agent talking to devcap -- but the capability to start a functional authentication agent is guarded by capability tokens. You need to be authenticated to allow authentication.

Removing suid binaries with config files as a method for privilege escalation is the right path. They don't play well with namespaces.

Cryptographic capability tokens that you can delegate to other programs do.

[DarylZero]

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.

[ori_b]

> 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.

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.