4 ms·

I agree it can be inconvenient but don't iOS and Android kind of show that for most users the experience can be just fine? For us devs we can still either open

I agree it can be inconvenient but don't iOS and Android kind of show that for most users the experience can be just fine? For us devs we can still either open our systems or find better ways but I'd prefer the default to be more closed. I'd also prefer the default to be VM-ish. Right now I have 275 projects in my /home/me/src folder. Every one of them has at least a build process that executes code I have mostly not reviewed. Many of them execute more code after being built. Some of them execute code when they were installed for dependencies. Maybe I'm just not used to it but I'd really like if the process for isolating all 275 of those projects was somehow easier. Or maybe I'd prefer they were all isolated by default and that we could work on ways of making them easy to do the things they really need to do and hard/discouraged to do anything that would also be a security issue. Maybe people have suggestions. I don't want an actual VM if it means I have to install 275 copies of OSes and 275 sets of semi global dependencies (like I don't want to have to install python 3.8 200 times) but I do want all 275 of those projects not to be able to read my private keys or my photos etc or write outside designated areas

fock 7y ago
you could use some lightweight rootless containers: I wrapped bubblewrap in a small python-program parsing a YAML-configuration (which mirrors my hosts rootfs and provides "topical" homes: node, python, scientific stuff), but there is also something like toolbox: https://github.com/containers/toolbox/blob/master/README.md https://github.com/containers/toolbox/blob/master/README.md Note that you need to secure your X-Server also, especially when sharing your network-namespace... (as it might be configured to authenticate your uid on (anonymous) sockets)
- dredmorbius 7y ago
  Containers (and virtualisation) are helpful but. not bulletproof. If your threat model is already malicious code with ill intent, you probably want higher grades of privsep / sandboxing. E.g., https://www.twistlock.com/labs-blog/escaping-docker-container-using-waitid-cve-2017-5123/ https://www.twistlock.com/labs-blog/escaping-docker-containe... https://www.exploit-db.com/exploits/46978 https://www.exploit-db.com/exploits/46978 Full virtualisation does far better, though I believe there've been exploits there as well. Yes, from 2015: https://threatpost.com/xen-patches-7-year-old-vm-escape-hypervisor-vulnerability/115206/ https://threatpost.com/xen-patches-7-year-old-vm-escape-hype...
  - cyphar 7y ago
    Docker has had it's fair share of breakouts because the default configuration doesn't use user namespaces (one of the most significant security isolation features in Linux) and runs as root. It's not indicative of how secure a properly set up container is -- I don't remember the last time there was an LXC or LXD breakout (which use user namespaces by default). Source: I've found a fair few Docker breakouts. I also maintain runc, which is the lower-level container runtime component (where most of the breakouts are found).
    - feanaro 7y ago
      Don't user namespaces have significant security issues themselves?
      - cyphar 7y ago
        There have been security bugs involving allowing unprivileged user namespaces, but that doesn't matter at all in this case -- seccomp is used by effectively all container runtimes to block things like CLONE_NEWUSER inside containers.
  - brunoff 7y ago
    Some effort towards more secure containers: https://gvisor.dev/ https://gvisor.dev/
simias 7y ago
The problem with existing OSs is that if you don't make it the default and force everybody to adapt you end up with a half-assed solution with bad support that just gets in the way. I tried to use firejail to sandbox critical apps (mainly my browser, but also the closed source Spotify client for instance) but eventually gave up because it would just break too often. On top of that the one app I'd like to sandbox more is obviously the web browser, but since nowadays web browsers are like a full OS on top of another it's really hard to finely grain permissions unless you want one profile per website. The browser needs access to the filesystem if you want to upload and download files, the graphics card if you want good performance and webgl, the sound API if you want audio, the ability to fullscreen if you want to be able to play games and videos that way, the printer if you want to print stuff, the USB stack if you want to use security tokens etc...

fock 7y ago

you could use some lightweight rootless containers: I wrapped bubblewrap in a small python-program parsing a YAML-configuration (which mirrors my hosts rootfs and provides "topical" homes: node, python, scientific stuff), but there is also something like toolbox: https://github.com/containers/toolbox/blob/master/README.md https://github.com/containers/toolbox/blob/master/README.md Note that you need to secure your X-Server also, especially when sharing your network-namespace... (as it might be configured to authenticate your uid on (anonymous) sockets)

dredmorbius 7y ago
Containers (and virtualisation) are helpful but. not bulletproof. If your threat model is already malicious code with ill intent, you probably want higher grades of privsep / sandboxing. E.g., https://www.twistlock.com/labs-blog/escaping-docker-container-using-waitid-cve-2017-5123/ https://www.twistlock.com/labs-blog/escaping-docker-containe... https://www.exploit-db.com/exploits/46978 https://www.exploit-db.com/exploits/46978 Full virtualisation does far better, though I believe there've been exploits there as well. Yes, from 2015: https://threatpost.com/xen-patches-7-year-old-vm-escape-hypervisor-vulnerability/115206/ https://threatpost.com/xen-patches-7-year-old-vm-escape-hype...
- cyphar 7y ago
  Docker has had it's fair share of breakouts because the default configuration doesn't use user namespaces (one of the most significant security isolation features in Linux) and runs as root. It's not indicative of how secure a properly set up container is -- I don't remember the last time there was an LXC or LXD breakout (which use user namespaces by default). Source: I've found a fair few Docker breakouts. I also maintain runc, which is the lower-level container runtime component (where most of the breakouts are found).
  - feanaro 7y ago
    Don't user namespaces have significant security issues themselves?
    - cyphar 7y ago
      There have been security bugs involving allowing unprivileged user namespaces, but that doesn't matter at all in this case -- seccomp is used by effectively all container runtimes to block things like CLONE_NEWUSER inside containers.
- brunoff 7y ago
  Some effort towards more secure containers: https://gvisor.dev/ https://gvisor.dev/

simias 7y ago

The problem with existing OSs is that if you don't make it the default and force everybody to adapt you end up with a half-assed solution with bad support that just gets in the way. I tried to use firejail to sandbox critical apps (mainly my browser, but also the closed source Spotify client for instance) but eventually gave up because it would just break too often. On top of that the one app I'd like to sandbox more is obviously the web browser, but since nowadays web browsers are like a full OS on top of another it's really hard to finely grain permissions unless you want one profile per website. The browser needs access to the filesystem if you want to upload and download files, the graphics card if you want good performance and webgl, the sound API if you want audio, the ability to fullscreen if you want to be able to play games and videos that way, the printer if you want to print stuff, the USB stack if you want to use security tokens etc...