It's kind of funny that this argument always comes up when talking about Windows security.
What if I told you that botched sandboxing by default is not the standard we should accept? And that Windows' lack of competence to isolate processes isn't even what the NT Kernel envisioned (see e.g. ReactOS)?
I'd never run Windows as a host system, given the track record of how Microsoft deals with RCEs and privilege escalation issues that have been unfixed for decades at this point.
* Arguing about what should be doesn't alter the facts of the current situation
* It's unfair to single out Windows here, when other platforms are not much better. Mechanisms for stronger sandboxing and storage firewalling do exist on all platforms, but in practice these are barely used on desktops, and this is true across all three major OS families. E.g. Flatpaks exist, but I believe they still represent the minority of actual application installs
And ironically Wayland also gets frequent, heavy criticism for doing the right thing here - treating screen or input capture as a privileged operation, rather than a default right of any random application you have running (though I agree they should have standardized an escape hatch earlier)
I do not want stronger sandboxing for my apps. I'll only allow it to run on my machine if I trust it anyway. I'm not worried about my apps being able to read my data. If a piece of software doesn't do what I want safely and securely, then I don't try to duct-tape it into a sandbox that's regularly broken out of anyway. I remove and use other software.
If flatpak/appimage are the only way to get a piece of software, I won't even waste my time evaluating it.
No, I don't. Because it doesn't need to. But not running as root already provides all the protection I want. System files are not my data. My data lives in my home. I want my apps to have access to my stuff, not the whole system. But more importantly, I do want them to be able to talk to each other and effortlessly open files written by one another. "Isolating" them from each other is pointless if I then proceed to punch holes in everything just so it can work.
"This thing isn't working ... "Oh... it turns out it was missing a permission, should I give it that permission? What's it for? Fuck if I know..."
Or the other way round:
"This app seems like it's working properly, but can I restrict this particular permission for it? Fuck if I know. I'll just try and see if anything is broken"
Or I can just run the application normally and have everything always work.
You should dig into ~/.local and what happens there. I'd never store my keepassxc database file in my home folder if I were you.
Apps need sandboxing, because the linux/posix philosophy of separation through users and groups for each process doesn't really work in the modern day and how graphical software works.
Firejail's approach comes close to "sane" user sandboxes, but technically that's the job of the init daemon (pid 0), there's just no GUI for systemd sandboxes yet that's easily usable.
Podman is also really nice as a user-facing sandboxing daemon.
i know what happens in there. Shit that I install because I want to goes in there. And my keepassxc password is protected by a strong password and a hardware token. They are specifically designed so you can safely store them anywhere (ex cloud backup), so I don't see why you brought that specific example up
Well, I agree with the Wayland and copy/paste clusterfvck.
I was more referring towards Qubes. I think Qubes does a lot of things right, I just wish its user facing settings and tools were easier to use in a graphical manner.
It's the same security for the Signal as on MacOS and Linux. Your user has full control to it, generally all processes running as you can see it and mess with it.
What if I told you that botched sandboxing by default is not the standard we should accept? And that Windows' lack of competence to isolate processes isn't even what the NT Kernel envisioned (see e.g. ReactOS)?
I'd never run Windows as a host system, given the track record of how Microsoft deals with RCEs and privilege escalation issues that have been unfixed for decades at this point.