Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bell Labs' Plan 9 research project looks to tomorrow (1990)

doc.cat-v.org

Post reply on HN
Print view View original

61–70 of 75 posts

Re: Bell Labs' Plan 9 research project looks to tomorrow (1990)

#61

Post by stormbrew »

DarylZero wrote: post #51
stormbrew wrote: post #30

Earlier quoted context omitted.

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 co…

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 mech…

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

Re: Bell Labs' Plan 9 research project looks to tomorrow (1990)

#62

Post by stormbrew »

lizknope wrote: post #12
stormbrew wrote: post #5

Earlier quoted context omitted.

I would call it maybe vageuly similar, but it is by no means a subset. It has some features in common and many that are completely nonsense in a posix context. The most pressing problem for implementing plan9-like semantics in a POSIX system is the permission system. In particular, setuid as a mechanism for privilege escalation. This is a big part of why users can't make their own namespaces on linux without help/int…

Capabilities were supposed to split up the need to having a single root account that could do everything. I'm not sure how far it has gone. https://tbhaxor.com/understanding-linux-capabilities/ https://blog.container-solutions.com/linux-capabilities-in-p...

They're a good step but they're really a step in a different direction, even though capabilities are at the heart of how plan9 does permissions as well. Plan9 capabilities are more like kerberos tokens, so you get them from privileged services and then can use them to perform privileged actions.

Linux capabilities don't really change any of the issues around namespace security because they don't inherently provide a way to elevate privileges without setuid.

Re: Bell Labs' Plan 9 research project looks to tomorrow (1990)

#63

Post by DarylZero »

ori_b wrote: post #57
DarylZero wrote: post #51

Earlier quoted context omitted.

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 mech…

> 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 so…

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.

Re: Bell Labs' Plan 9 research project looks to tomorrow (1990)

#64

Post by stormbrew »

DarylZero wrote: post #63
ori_b wrote: post #57

Earlier quoted context omitted.

> 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 so…

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.

setuid does not exist on plan9.

Re: Bell Labs' Plan 9 research project looks to tomorrow (1990)

#65

Post by DarylZero »

stormbrew wrote: post #64
DarylZero wrote: post #63

Earlier quoted context omitted.

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.

setuid does not exist on plan9.

Right, so none of this namespace stuff works under suid there either.

Re: Bell Labs' Plan 9 research project looks to tomorrow (1990)

#66

Post by stormbrew »

DarylZero wrote: post #65
stormbrew wrote: post #64

Earlier quoted context omitted.

setuid does not exist on plan9.

Right, so none of this namespace stuff works under suid there either.

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.

Re: Bell Labs' Plan 9 research project looks to tomorrow (1990)

#67

Post by DarylZero »

stormbrew wrote: post #66
DarylZero wrote: post #65

Earlier quoted context omitted.

Right, so none of this namespace stuff works under suid there either.

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.

Re: Bell Labs' Plan 9 research project looks to tomorrow (1990)

#68

Post by stormbrew »

DarylZero wrote: post #67
stormbrew wrote: post #66

Earlier quoted context omitted.

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…

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.

Please just read some things about plan9 already.

Re: Bell Labs' Plan 9 research project looks to tomorrow (1990)

#69

Post by [deleted] »

DarylZero wrote: post #63
ori_b wrote: post #57

Earlier quoted context omitted.

> 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 so…

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.

[deleted]

Re: Bell Labs' Plan 9 research project looks to tomorrow (1990)

#70

Post by ori_b »

DarylZero wrote: post #67
stormbrew wrote: post #66

Earlier quoted context omitted.

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…

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

Post reply on HN