4 ms·

All it takes is a browser exploit. We've had plenty of browser exploits for any given browser, sandboxing the entire program a la containers is the most effect

All it takes is a browser exploit. We've had plenty of browser exploits for any given browser, sandboxing the entire program a la containers is the most effective mitigation outside of running it in a dedicated vm.

jolmg 7y ago
All it takes is a browser exploit, in any OS. What does the possible existence of exploits have to do with macOS being more secure than Linux? macOS can also have exploits. I don't understand where your claim that there's a specific risk of unrestrained file access to websites comes from. In my eyes, saying that it could be true because exploits could exist nullifies everything you said. You could apply that argument to everything: There is a substantial risk in iPhones giving websites unrestrained access to making phone calls on your behalf because all it takes is an exploit.
- deleted 7y ago
  [deleted]
- newnewpdro 7y ago
  Different OSes have different sandboxing capabilities. Until relatively recently, Linux had effectively none, just chroot, and selinux which almost everyone disabled for a decade. The point, which you seem to be missing, is that with generalized sandboxing tools like containers, you can isolate any application to limit the potential damage of application exploits. It's a form of defense in depth. We must assume browsers have many bugs and are exploitable. Ok, from that perspective, what do we do to safely access untrusted input (the entire internet) with the browser on a computer we also do things like banking, private communications, and access privileged servers from? We run it in either a dedicated VM or more recently, we use sandboxing technologies like containers. I don't understand why this is so difficult for you to grok.
  - jolmg 7y ago
    You keep trying to shift this conversation into sandboxing. Of course, any form of sandboxing is going to add defense in depth to anything. It isn't of any particular relevance to this conversation. You said: > Unless you're going out of your way to run your browser in a container or dedicated VM on Linux, there are substantial risks associated with browsing the web in terms of exposing all of your information in /home, which might include ssh and pgp private keys, basically everything your user can access. You're saying that there's this particular substantial risk in this particular OS, in this particular scenario. When I ask for any details that can back it up, you reply "All it takes is a browser exploit". I would hope it would be self-evident that that is no reason to think that the particular risk you mentioned is real, or at least any more real than it is for any other OS, for any other app, or in any other circumstance. My only interest in the comment was determining if the particular risk is real, but now it seems it was just FUD.
    - cycloptic 7y ago
      It's not FUD, that person is telling the truth. Don't interpret it the wrong way though. Browser exploits are a popular 0-day on any platform and it is indeed likely the security situation on other platforms is just as bad.
  - curt15 7y ago
    >Until relatively recently, Linux has effectively none, just chroot, and selinux which almost everyone disabled for a decade. Chrome has long used several Linux sandboxing features, namely user namespaces and seccomp-bpf [1]. [1] https://chromium.googlesource.com/chromium/src.git/+/master/docs/linux_sandboxing.md https://chromium.googlesource.com/chromium/src.git/+/master/...
    - newnewpdro 7y ago
      Chrome was also found to be secretly downloading binary blobs for execution, we should not be trusting Chrome's sandboxing exclusively to protect us from the internet, we can't even trust Chrome itself. [0] In-browser sandboxing is more for attempting to isolate tabs from accessing one another's state. It can't be relied upon exclusively for protecting the larger host from the browser itself. One should really put the entire browser in a sandbox where it can only access data and functionality necessary for its operation. Nothing more. How one achieves that, what tools is at their disposal, is greatly OS-dependent and that's the core of my point. On Linux systems, the out-of-box configuration for most distros is to just run the browser on the host with no sandboxing. It's not sufficient. Flatpak is one of the active efforts to fix this. If you run firefox or chrome from a flatpak, it will be run in isolation, and accessing external host resources will be done in a controlled fashion via portals or explicitly enumerated mounts in the manifest. As mentioned elsewhere, I used firejail in the past but now prefer systemd-nspawn containers, often ephemeral ones that are spun up and thrown away per browser session. [0] https://www.theregister.co.uk/2015/06/17/debian_chromium_hubbub/ https://www.theregister.co.uk/2015/06/17/debian_chromium_hub...
johnisgood 7y ago
I think the misunderstanding here is that you did not answer the actual question, which is, what makes Linux less secure in comparison to macOS? What you mentioned applies to all OSes, and does not answer the question.

jolmg 7y ago

All it takes is a browser exploit, in any OS. What does the possible existence of exploits have to do with macOS being more secure than Linux? macOS can also have exploits. I don't understand where your claim that there's a specific risk of unrestrained file access to websites comes from. In my eyes, saying that it could be true because exploits could exist nullifies everything you said. You could apply that argument to everything: There is a substantial risk in iPhones giving websites unrestrained access to making phone calls on your behalf because all it takes is an exploit.

deleted 7y ago
[deleted]
newnewpdro 7y ago
Different OSes have different sandboxing capabilities. Until relatively recently, Linux had effectively none, just chroot, and selinux which almost everyone disabled for a decade. The point, which you seem to be missing, is that with generalized sandboxing tools like containers, you can isolate any application to limit the potential damage of application exploits. It's a form of defense in depth. We must assume browsers have many bugs and are exploitable. Ok, from that perspective, what do we do to safely access untrusted input (the entire internet) with the browser on a computer we also do things like banking, private communications, and access privileged servers from? We run it in either a dedicated VM or more recently, we use sandboxing technologies like containers. I don't understand why this is so difficult for you to grok.
- jolmg 7y ago
  You keep trying to shift this conversation into sandboxing. Of course, any form of sandboxing is going to add defense in depth to anything. It isn't of any particular relevance to this conversation. You said: > Unless you're going out of your way to run your browser in a container or dedicated VM on Linux, there are substantial risks associated with browsing the web in terms of exposing all of your information in /home, which might include ssh and pgp private keys, basically everything your user can access. You're saying that there's this particular substantial risk in this particular OS, in this particular scenario. When I ask for any details that can back it up, you reply "All it takes is a browser exploit". I would hope it would be self-evident that that is no reason to think that the particular risk you mentioned is real, or at least any more real than it is for any other OS, for any other app, or in any other circumstance. My only interest in the comment was determining if the particular risk is real, but now it seems it was just FUD.
  - cycloptic 7y ago
    It's not FUD, that person is telling the truth. Don't interpret it the wrong way though. Browser exploits are a popular 0-day on any platform and it is indeed likely the security situation on other platforms is just as bad.
- curt15 7y ago
  >Until relatively recently, Linux has effectively none, just chroot, and selinux which almost everyone disabled for a decade. Chrome has long used several Linux sandboxing features, namely user namespaces and seccomp-bpf [1]. [1] https://chromium.googlesource.com/chromium/src.git/+/master/docs/linux_sandboxing.md https://chromium.googlesource.com/chromium/src.git/+/master/...
  - newnewpdro 7y ago
    Chrome was also found to be secretly downloading binary blobs for execution, we should not be trusting Chrome's sandboxing exclusively to protect us from the internet, we can't even trust Chrome itself. [0] In-browser sandboxing is more for attempting to isolate tabs from accessing one another's state. It can't be relied upon exclusively for protecting the larger host from the browser itself. One should really put the entire browser in a sandbox where it can only access data and functionality necessary for its operation. Nothing more. How one achieves that, what tools is at their disposal, is greatly OS-dependent and that's the core of my point. On Linux systems, the out-of-box configuration for most distros is to just run the browser on the host with no sandboxing. It's not sufficient. Flatpak is one of the active efforts to fix this. If you run firefox or chrome from a flatpak, it will be run in isolation, and accessing external host resources will be done in a controlled fashion via portals or explicitly enumerated mounts in the manifest. As mentioned elsewhere, I used firejail in the past but now prefer systemd-nspawn containers, often ephemeral ones that are spun up and thrown away per browser session. [0] https://www.theregister.co.uk/2015/06/17/debian_chromium_hubbub/ https://www.theregister.co.uk/2015/06/17/debian_chromium_hub...

johnisgood 7y ago

I think the misunderstanding here is that you did not answer the actual question, which is, what makes Linux less secure in comparison to macOS? What you mentioned applies to all OSes, and does not answer the question.