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

71–75 of 75 posts

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

#71

Post by DarylZero »

ori_b wrote: post #70
DarylZero wrote: post #67

Earlier quoted context omitted.

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

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.

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

#72

Post by NavinF »

stormbrew wrote: post #60
DarylZero wrote: post #52

Earlier quoted context omitted.

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

Ahh finally a real use case in this thread.

Last time I ran into the “edit an ext4 image as an unprivileged user” problem I used a small VM.

There are people trying to fix this problem and there’s a legitimate reason why it’s hard: https://lwn.net/Articles/755593/

IIRC the patches needed for what’s described in that article are already there on Ubuntu.

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

#73

Post by stormbrew »

NavinF wrote: post #72
stormbrew wrote: post #60

Earlier quoted context omitted.

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

Ahh finally a real use case in this thread. Last time I ran into the “edit an ext4 image as an unprivileged user” problem I used a small VM. There are people trying to fix this problem and there’s a legitimate reason why it’s hard: https://lwn.net/Articles/755593/ IIRC the patches needed for what’s described in that article are already there on Ubuntu.

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.

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

#74

Post by ori_b »

DarylZero wrote: post #71
ori_b wrote: post #70

Earlier quoted context omitted.

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

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

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

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

#75

Post by NavinF »

stormbrew wrote: post #73
NavinF wrote: post #72

Earlier quoted context omitted.

Ahh finally a real use case in this thread. Last time I ran into the “edit an ext4 image as an unprivileged user” problem I used a small VM. There are people trying to fix this problem and there’s a legitimate reason why it’s hard: https://lwn.net/Articles/755593/ IIRC the patches needed for what’s described in that article are already there on Ubuntu.

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

> moving all filesystem operations out of the kernel

Well yeah, that’s exactly what FUSE + user namespaces does to solve this problem on Linux.

Of course normal filesystems don’t do this because it would be way too slow if the kernel can’t share data structures with the file system.

Post reply on HN