>I avoid arbitrary web browsing on my Linux laptop and just use it for coding.
What makes web browsers less secure on Linux than on macOS?
What makes web browsers less secure on Linux than on macOS?
But we have a number of solutions for running things in containers if you just use them. Early on firejail was popular, these days I just run nspawn containers for browser instances and bind mount in some stuff for a shared Downloads directory etc.
I can't speak to how that compares to OSX as I've never used it, but it is worth noting that the security story on Linux can range from bad to somewhat OK depending on your setup.
Edit:
In responses people seem to be completely ignoring that I already stated above in my original comment that I can't speak to how it compares to OSX. I don't know what OSX is doing for application sandboxing defaults.
I can however speak with some authority on the Linux situation. And today, if you're running firefox/chrome as your regular user as installed by apt/yum etc, without any additional sandboxing, and that user has access to secrets like ssh/gpg private keys, you're being unnecessarily reckless. And unfortunately that is basically the default way browsers are run today on most distributions
This is a major reason why the Flatpak/GNOME people have been working so hard on portals and namespaces are an integral component of the runtime. It's not just about application distribution. They're trying to close a major security hole in desktop linux as it's often used today. They want applications like the browser run in its own namespaces with just the minimum of host filesystem paths bind mounted in.
There's absolutely no reason for your browser process to have the ability to access all of your private keys, just because they happen to be under the home directory it happens to have access to, full stop.
What are you talking about? You're saying that a random website is given unrestricted file access to everything the user can access. Can you back that up with a concrete example or a link explaining the issue or something?
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.
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.
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.
Chrome has long used several Linux sandboxing features, namely user namespaces and seccomp-bpf [1].
[1] https://chromium.googlesource.com/chromium/src.git/+/master/...
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_hub...
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.
Relying on the browser alone for sandboxing is problematic as the dominant browsers can't really be trusted. It's best to sandbox the entire program, in addition to their internal sandboxing techniques.