6 ms·

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 i

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.

ori_b 5y ago
You understood the problem backwards. How do you give out actual, real, global root, without taking away the ability to do arbitrary namespaces?
- DarylZero 5y ago
  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.
  - ori_b 5y ago
    And how does that interact with binding files as non-root, including /etc/sudoers.conf? (plan 9 has no suid, so this is not a problem there)
    - DarylZero 5y ago
      I said more about that in the thread already.
- sillysaurusx 5y ago
  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.
  - stormbrew 5y ago
    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.
    - DarylZero 5y ago
      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.
      - stormbrew 5y ago
        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).
        NavinF 5y ago
        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/ https://lwn.net/Articles/755593/ IIRC the patches needed for what’s described in that article are already there on Ubuntu.
stormbrew 5y ago
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.
- deleted 5y ago
  [deleted]
- DarylZero 5y ago
  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.

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.

ori_b 5y ago

You understood the problem backwards. How do you give out actual, real, global root, without taking away the ability to do arbitrary namespaces?

DarylZero 5y ago
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.
- ori_b 5y ago
  And how does that interact with binding files as non-root, including /etc/sudoers.conf? (plan 9 has no suid, so this is not a problem there)
  - DarylZero 5y ago
    I said more about that in the thread already.
sillysaurusx 5y ago
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.
- stormbrew 5y ago
  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.
  - DarylZero 5y ago
    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.
    - stormbrew 5y ago
      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).
      - NavinF 5y ago
        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/ https://lwn.net/Articles/755593/ IIRC the patches needed for what’s described in that article are already there on Ubuntu.

stormbrew 5y ago

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.

deleted 5y ago
[deleted]
DarylZero 5y ago
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.