In modern Linux this is no problem. You can now give a process its own UID namespace. In the calling namespace its UID is non-zero, but in its own namespace it's root.
I dunno about the sibling comment's "backwards" comment but the thing here is that the goal isn't to prevent a user process from obtaining privileges, which is what uid namespaces are for.
This is the kind of thing I mean about "not knowing what you don't know," because you're looking at namespaces through the lens linux does, which is that they exist to limit capabilities.
Plan 9 uses namespaces to allow users to control their own environment. It's not a special operation, it's just a thing you do all the time.
For a small practical example: there's no PATH environment variable in plan9. You just union mount things into /bin, and /bin is where your shell looks for things to run. It's that much of an every day operation.
If you put a user under a uid namespace in linux, and then give them the right to create their own filesystem namespaces then sure, you've enabled them to potentially do things like this. But you've also blocked them from escalating their privileges, because now they can't use setuid binaries to obtain "real root" or whatever.
So you're left with one or the other: either you can manage your own namespace, but you have to be protected from potentially breaching root security through a setuid or cap flag on a binary; or you have to be prevented from managing your namespace outright in order to avoid lying to sudo about who can do what.
The thing about `sudo` is confusing because you don't even need to modify the namespace to overwrite `/etc/sudoers` if you have root. You just need to write to the file.
What it sounds like plan9 is doing is giving a local view of the root that local processes see. Which Linux can do too. Not with the same use-cases in mind as Plan9 though, as such capabilities were added for sandboxing/containerization. But the mechanisms are probably(?) general enough to do Plan9 in Linux.
A `sudo` that is seeing a local view of the root is going to have privileged access to that local root, not to the global system root. And that is correct. That is what sudo does. It gives root access to the same root that contains /etc, not to any "outer" or "more global" root.
It doesn't mean you can't have any access to the global root from the local root though. There are many ways to arrange such privilege escalation. (They do have to be arranged, of course, by someone writing the userspace code -- like sudo had to be written.)
>If you put a user under a uid namespace in linux, and then give them the right to create their own filesystem namespaces then sure, you've enabled them to potentially do things like this. But you've also blocked them from escalating their privileges, because now they can't use setuid binaries to obtain "real root" or whatever.
Privileged processes can have a global view of the namespace while the user does not. An ordinary setuid binary on a filesystem the user controls can't get a global view, only because the user does not (should not) have authority to do that. A process with the global view and root can grant the authority though.
The important thing, it seems to me, is that the global outer namespace can grant to the process local namespace any capabilities available through the outer namespace. I'm not sure if this is 100% completed but the ongoing containerization efforts do involve reaching toward that 100% mark.
> The thing about `sudo` is confusing because you don't even need to modify the namespace to overwrite `/etc/sudoers` if you have root. You just need to write to the file.
The point is that you DONT have root, and you DONT have access to write to the file. But you're free to rearrange your namespace WITHOUT having root, and you want to arrange for SOME users to escalate privileges and, say, debug the kernel. Or do something else dangerous that requires elevated privileges in the global context.
> A `sudo` that is seeing a local view of the root is going to have privileged access to that local root, not to the global system root. And that is correct. That is what sudo does. It gives root access to the same root that contains /etc, not to any "outer" or "more global" root.
Yes, and that's a concise description of the flaw: you can't use suid+file based privilege escalation to modify system-wide configuration, without restricting the ability to manage freely your namespace.
This is what unix does by design, and why the authentication design from unix isn't going to work for systems used in the style of plan 9.
You can use suid programs to do what they do. You can use other mechanisms to do other things.
Suid programs on Plan9 could not possibly behave any differently. If the user rebinds `/bin` and then runs a suid program that calls other programs, that suid program cannot use the rebound `/bin`. That kind of binding simply can't be allowed to cross security contexts.
I don't know what you're trying to say here. You seem to be saying that "namespaces wouldn't work in plan9 if plan9 had setuid" which.. yes? That's exactly right. But plan9 does have namespaces, and does not have setuid, so it does indeed work there.
I mean it's supposed to be a problem for Linux if a setuid binary just has a different namespace view than the caller. But in Plan9 there's no setuid binary at all yet it's not a problem?
In neither Plan9, nor Linux, nor any other potential system, could you have the caller of a privileged program control the namespaces accessed under the privilege of that program.
Like the whole thing about rebinding /bin instead of $PATH... well neither rebinding, nor editing $PATH, nor any other such thing, $LD_PRELOAD, anything, that would affect how the process found files to execute, could be secure if allowed to affect a privileged process. It only means you disable environment sharing, and you disable namespace sharing, etc., any other kind of sharing (no matter how implemented... Linux way, Plan9 way, anything). Plan9 has no better way than that, no way to make /bin rebinding work in a way that makes sense for privilege escalation.
> 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.
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.
> 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.
The problem is that the setuid program does have the same view of the namespace as its caller. When you run a setuid binary it inherits all aspects of the process that exec()'d it, including its namespaces.
Ok, so let's make this more concrete. The scenario we're discussing is a user who wishes to (illegitimately) elevate their privileges, and has the ability to mount, and in particular bind/union mount:
> mkdir ~/my-etc
> echo 'badperson ALL=NOPASSWD:(ALL:ALL) ALL' > ~/my-etc/sudoers
> mount --bind ~/my-etc /etc # note: you could also insert a command to bump us into a new filesystem namespace before this if you want, or assume that say logind did it for us, it wouldn't change anything about what happens next
> sudo -s
# rm -rf /*
This happens because sudo is a setuid program, and it inherits the filesystem namespace of the shell that ran it. In that namespace, the real sudoers file has been masked with a fake one that says badperson can sudo to any user they want, and so it lets them.
That this is the mechanism of privilege escalation that linux uses is fundamental to why mounting (and bind mounting) is a privileged operation. Plan9 does not have either root, nor setuid programs, nor filesystem-stored capabilities, and so does not suffer from this and you can manipulate your namespace to your heart's content.
> Plan9 has no better way than that, no way to make /bin rebinding work in a way that makes sense for privilege escalation.
> But the mechanisms are probably(?) general enough to do Plan9 in Linux.
They are not. The whole point of this subthread is that the ability to create namespaces as an unprivileged user[1] would be key to actually 'doing plan9 in linux'. You can not believe that if you want, but I'd suggest you read up a bit more on plan9 if so, because it becomes obvious pretty quick that it's the case.
[1] And here by 'unprivileged user' I mean someone who is still a user of the machine, and not a user who has been containered away into a separate user namespace, let alone into a whole docker-style container.
I feel like plan9 nerds (of which I’m one) are missing the point. People are asking “what’s so special about plan9?” and the best response is some esoteric point about a thing people empirically don’t want to do? Who cares?
There has to be a better answer than “Wow, I can make my computer that can’t run anything people want to run secure in a hypothetical hierarchical organization structure of permissions that can each have their own subtree sudo. I even call it treedo, ha-ha!” .. it just doesn’t resonate.
I dunno I think the positives are all actually pretty practical. Probably even more so today where heterogeneous computing is so much more common than it was in the 90s.
I would frequently love to have the ability to just mount a bunch of cpus off a beefier machine onto my laptop and take advantage of that to speed up my builds. I can use DISTCC but holy hell is it a lot more complicated to set up.
Or like, mounting a zip file as a directory, without needing a whole enormous systemd or gnome hairball along with fuse or gfs to make it happen as a regular user. Or hell, mount a usb stick even!
These are literally things I wish were easier every day as a software developer. The vaguely plan9-shaped bits that have been added to linux over the years have brought me no closer to them.
Fuse is how it works on Linux. Fuse is the mechanism the kernel provides to do this. So the proviso "without needing ... fuse ... to make it happen as a regular user" is terminal.
You can't mount even a fuse filesystem without root privileges (or an equivalent narrow capability). Mount is a privileged operation in linux, and it has to be for the reasons I've outlined.
In plan9 mount is not a privileged operation. Anyone can do it at any time for any reason. It does not impact or interact with the security of the system (except that you can implicitly remove access to things by unmounting them).
I mean, yes? People are 'trying', and they're building an ever higher house of cards on which to rest this functionality. Obviously on a turing complete machine anything is possible given enough LoC, but as we've seen recently with a CVE for privilege escalation that takes advantage of one of these new 'unprivileged user can get privileges in a namespace' tricks, there's a lot of complexity and likely a lot of security issues hiding behind it.
Plan9's design makes all of this very simple, and a big part of why is the specific choice to eschew standard UNIX semantics and use a different kind of mechanism for privilege management that allowed for flexible namespaces managed outside the kernel. It also has the advantage of moving all filesystem operations out of the kernel.
So this really backs up my point, rather than contradicts it: It's only through mitigating and otherwise contradicting traditional POSIX semantics that linux is able to approach this kind of thing.
The problem here is boring and practical: how do you make `bind` (or, in Linux land) `mount --bind` secure and still allow you to authenticate as a separate user, elevate permissions to change kernel config, and so on?
The authentication mechanisms on most Linuxes are based around suid binaries that read configuration files in order to decide on what to do, so if you can bind in a namespace, you can fool the authentication mechanisms.
In plan 9, this is solved with the kernel capability device. It's not particularly exciting, it's just one of the things that need to happen when you remove the concept of a global 'root user' from the system.
I think you're right that I don't understand the problem.
If you want to give actual real global root, I think you can do it by having a gifting process put the real global root process into the same process namespace as the giftee process.
