5 ms·

I think we just stretched the 'unix' model in the wrong direction -- attempts to solve every problem, at every layer, all of the time. Trying to be everything t

by zbuf 6y ago

I think we just stretched the 'unix' model in the wrong direction -- attempts to solve every problem, at every layer, all of the time. Trying to be everything to everyone never works out very well. It would have been better to preserve users (UIDs) as the 'security' boundary for data. Leaving processes (PIDs) to offer the containment for safety (virtual memory etc.), and specifically not security of data. Then this specific case would only need the cache flushed on context switching between UIDs, but not all processes. Attempts to retro-fit security of data between processes are resulting in as much a negative as a positive -- eg. performance loss; or usability issues like regular users on Linux gdb'ing their own processes now has to be explicitly enabled by root. Of course, the new thing is all this untrusted code we're running; understood. I would suggest to preserve UIDs as the security boundary for data, then direct these issues through a mechanism that makes it as easy for an unprivileged user to 'fork' a UID for a purpose, just as they fork() a process. This gives a clear role to UIDs/PIDs and a sandboxing capability that makes use of all the existing implementation and boundaries.

wtallis 6y ago
From an end-user perspective, what really needs to happen is a new layer between UIDs and PIDs, corresponding to applications or services. It shouldn't matter whether under the hood an application uses multiple threads or multiple processes, as long as they're all contained to the same sandbox. I agree that fitting this model to current standard Unix capabilities probably means each application running under a separate UID—which is already common for services running on a server, but not for desktop/GUI applications.
- josteink 6y ago
  > I agree that fitting this model to current standard Unix capabilities probably means each application running under a separate UID Separate UIDs quickly get confusing too. I think such separation would be better done via cgroups and namespaces instead.
  - zbuf 6y ago
    No, I believe that misses my original point. cgroups and namespaces are privileged mechanisms that only 'root' can use, and share UIDs and other scopes across them (UID namespaces are complex and a risk in themselves.) It's required to re-implement all the required policy. Separate UIDs need get no more confusing than PIDs. I agree we really don't want /etc/passwd with a gazillion entries; we should only be managing them only as much as we "manage" temporary PIDs. But imagine a command to view the "UID" tree like the PID one. I agree it might not be how we'd design it if we designed from scratch. But then we may have chosen cgroups that integrated into the process tree and several other design decisions would change. The name "user" ID distorts the conversation because it's unintuitive, but I am suggesting that UIDs already embody much of the policy that is needed.
    - CountSessine 6y ago
      This is kind of what android does with selinux. Every app you install gets assigned a new UID on install. It seems to work quite well. Maybe we need this everywhere?
      - wtallis 6y ago
        We do, potentially with some modifications to make it easier for applications to interact with each other in novel ways once the user grants permission. Mobile operating systems are far ahead of desktop operating systems when it comes to making the "application" a first-class entity. macOS comes closest since most ordinary applications can be largely self-contained within the app bundle and the sandbox is steadily getting richer protection/isolation mechanisms. Linux applications have fairly well-controlled install and uninstall processes thanks to distro package managers, but post-install behavior cannot be managed with application granularity in any standard way (though there are some projects seeking to accomplish this, if they can first succeed in replacing existing distro package managers). And Windows is still largely allowing applications to spray files all over the disk and run whatever in the background. The challenge for the desktop is that we don't really want to switch from a multi-user paradigm (with all applications in the same security domain) to a single-user paradigm with per-application security domains. We need a multi-user OS with per-application security domains, and mobile operating systems aren't quite there. (I've heard that Android can be multi-user, but I've never encountered that functionality in the wild.)
- pantalaimon 6y ago
  > what really needs to happen is a new layer between UIDs and PIDs, corresponding to applications or services like cgroups?
  - wtallis 6y ago
    Cgroups are more about resource allocation than access control, but they may still be of some use under the hood (as they are for eg. docker). They certainly aren't the abstraction the end-user needs in order to enforce separation between application sandboxes.
josteink 6y ago
> It would have been better to preserve users (UIDs) as the 'security' boundary for data. Leaving processes (PIDs) to offer the containment for safety (virtual memory etc.), and specifically not security of data. Maybe I'm misunderstanding, but to me what you suggests sound like it would allow malicious JS running in my browser should be able to snoop data from my secure password manager (running as a separate process), because they both run under the same UID? Is that correct? Since most systems are pre-dominantly single-user systems, I honestly think the PID-isolation model makes more sense, as I'm not trying to defend against other users trying to spy on me, on my own laptop.
- zbuf 6y ago
  No, you're missing reading the whole post, specifically the last sentence. That's the one to quote me on. Your browser has the role of bringing in untrusted code, and running it. The browser code would 'fork' a UID to run the untrusted code (and only that), and then we make good use of all the existing UID-based policy in the kernel.
  - DaiPlusPlus 6y ago
    > The browser code would 'fork' a UID to run the untrusted code (and only that), and then we make good use of all the existing UID-based policy in the kernel. What would be the privilege set of that new UID though? And it would be a poor UX if that separate UID had absolutely zero access to my (human) UID-secured files because then it wouldn't be able to access my browser cache and history - and I'd rather Chrome didn't decide to require each browser process to have its own non-shared cache. It's bad enough Chrome is now using 3.5GB for 4 windows (16 tabs total) on my desktop.
    - zbuf 6y ago
      Try to not think in terms of whole applications. Chrome already has threads/processes dedicated to executing untrusted JavaScript code. What seems to be lacking is providing developers with an easy and non-root mechanism to run these as a different UID. To isolate the whole app should be possible, yes -- but it's also a sledgehammer. Yes, for the reason you describe, inter-operability with your own UID is actually good. My previous job taught me just how much this can be a feature not a bug; we made extensive use of applications, plugins and various forms of IPC to allow desktop applications to inter-operate in powerful ways. There are other mechanism already exist. When a process (or thread) is forked, various resources can be passed over the boundary; file descriptors, shared memory etc.. For example, where un-trusted code needs access to a file, the mechanism to do that is already there in a nice "opt-in" manner.

by zbuf 6y ago

wtallis 6y ago

From an end-user perspective, what really needs to happen is a new layer between UIDs and PIDs, corresponding to applications or services. It shouldn't matter whether under the hood an application uses multiple threads or multiple processes, as long as they're all contained to the same sandbox. I agree that fitting this model to current standard Unix capabilities probably means each application running under a separate UID—which is already common for services running on a server, but not for desktop/GUI applications.

josteink 6y ago
> I agree that fitting this model to current standard Unix capabilities probably means each application running under a separate UID Separate UIDs quickly get confusing too. I think such separation would be better done via cgroups and namespaces instead.
- zbuf 6y ago
  No, I believe that misses my original point. cgroups and namespaces are privileged mechanisms that only 'root' can use, and share UIDs and other scopes across them (UID namespaces are complex and a risk in themselves.) It's required to re-implement all the required policy. Separate UIDs need get no more confusing than PIDs. I agree we really don't want /etc/passwd with a gazillion entries; we should only be managing them only as much as we "manage" temporary PIDs. But imagine a command to view the "UID" tree like the PID one. I agree it might not be how we'd design it if we designed from scratch. But then we may have chosen cgroups that integrated into the process tree and several other design decisions would change. The name "user" ID distorts the conversation because it's unintuitive, but I am suggesting that UIDs already embody much of the policy that is needed.
  - CountSessine 6y ago
    This is kind of what android does with selinux. Every app you install gets assigned a new UID on install. It seems to work quite well. Maybe we need this everywhere?
    - wtallis 6y ago
      We do, potentially with some modifications to make it easier for applications to interact with each other in novel ways once the user grants permission. Mobile operating systems are far ahead of desktop operating systems when it comes to making the "application" a first-class entity. macOS comes closest since most ordinary applications can be largely self-contained within the app bundle and the sandbox is steadily getting richer protection/isolation mechanisms. Linux applications have fairly well-controlled install and uninstall processes thanks to distro package managers, but post-install behavior cannot be managed with application granularity in any standard way (though there are some projects seeking to accomplish this, if they can first succeed in replacing existing distro package managers). And Windows is still largely allowing applications to spray files all over the disk and run whatever in the background. The challenge for the desktop is that we don't really want to switch from a multi-user paradigm (with all applications in the same security domain) to a single-user paradigm with per-application security domains. We need a multi-user OS with per-application security domains, and mobile operating systems aren't quite there. (I've heard that Android can be multi-user, but I've never encountered that functionality in the wild.)
pantalaimon 6y ago
> what really needs to happen is a new layer between UIDs and PIDs, corresponding to applications or services like cgroups?
- wtallis 6y ago
  Cgroups are more about resource allocation than access control, but they may still be of some use under the hood (as they are for eg. docker). They certainly aren't the abstraction the end-user needs in order to enforce separation between application sandboxes.

josteink 6y ago

> It would have been better to preserve users (UIDs) as the 'security' boundary for data. Leaving processes (PIDs) to offer the containment for safety (virtual memory etc.), and specifically not security of data. Maybe I'm misunderstanding, but to me what you suggests sound like it would allow malicious JS running in my browser should be able to snoop data from my secure password manager (running as a separate process), because they both run under the same UID? Is that correct? Since most systems are pre-dominantly single-user systems, I honestly think the PID-isolation model makes more sense, as I'm not trying to defend against other users trying to spy on me, on my own laptop.

zbuf 6y ago
No, you're missing reading the whole post, specifically the last sentence. That's the one to quote me on. Your browser has the role of bringing in untrusted code, and running it. The browser code would 'fork' a UID to run the untrusted code (and only that), and then we make good use of all the existing UID-based policy in the kernel.
- DaiPlusPlus 6y ago
  > The browser code would 'fork' a UID to run the untrusted code (and only that), and then we make good use of all the existing UID-based policy in the kernel. What would be the privilege set of that new UID though? And it would be a poor UX if that separate UID had absolutely zero access to my (human) UID-secured files because then it wouldn't be able to access my browser cache and history - and I'd rather Chrome didn't decide to require each browser process to have its own non-shared cache. It's bad enough Chrome is now using 3.5GB for 4 windows (16 tabs total) on my desktop.
  - zbuf 6y ago
    Try to not think in terms of whole applications. Chrome already has threads/processes dedicated to executing untrusted JavaScript code. What seems to be lacking is providing developers with an easy and non-root mechanism to run these as a different UID. To isolate the whole app should be possible, yes -- but it's also a sledgehammer. Yes, for the reason you describe, inter-operability with your own UID is actually good. My previous job taught me just how much this can be a feature not a bug; we made extensive use of applications, plugins and various forms of IPC to allow desktop applications to inter-operate in powerful ways. There are other mechanism already exist. When a process (or thread) is forked, various resources can be passed over the boundary; file descriptors, shared memory etc.. For example, where un-trusted code needs access to a file, the mechanism to do that is already there in a nice "opt-in" manner.