4 ms·

It surprises me that Linux has no proper and detailed sandboxing out of the box. Are Linux users running untrusted closed-source applications and potentially ba

It surprises me that Linux has no proper and detailed sandboxing out of the box. Are Linux users running untrusted closed-source applications and potentially backdoored open-source programs with full privileges? Maybe they should just post their root password online, it won't get worse anyway.

cherryteastain 2y ago
Linux is a kernel. Let alone sandboxing, it does not even have an init process or bootloader by default. You can install all the utilities expected of a modern desktop OS if you want, and most distros will do it for you.
striking 2y ago
Not every app needs to be run with "full privileges" (or "as root" as some might call it), but it does usually end up being a binary decision on most distros if you're not careful. Either it can change everything or it can only affect the entire user profile it's running under. Bwrap and friends allow you to do a lot of extra isolation and get much more granular, but non-root console-only apps are generally safe to run (and safer still to run under their own user instead of yours).
yjftsjthsd-h 2y ago
Linux has lots of sandboxing features. Many Linux distros only use them minimally because the value proposition is poor: Most distros don't ship closed-source applications and in the last 30 years there have only ever been a tiny number of backdoored open source packages. OTOH, sandboxing tends to break the kind of complex workflows that users are fond of. Another angle to point out is that some distros do bake in more protective features; consider Fedora using SELinux. Then, again, keep considering SELinux and observe how many things it breaks the moment you set a single foot off the trodden path.
- mike_hearn 2y ago
  The Linux sandboxing features are mostly quite poor tbh. Compare to Apple's stack (if you include the private SBPL) and it doesn't come close. Apple is way ahead of both Windows and Linux when it comes to pervasive sandboxing.
  - yjftsjthsd-h 2y ago
    I'm not super familiar with Darwin, but I am skeptical on the grounds that macOS doesn't have containers, which are constructed from the same primitives as a sandbox.
    - mike_hearn 2y ago
      It does indeed have something similar to containers, built on their sandboxing tech rather than namespaces. Take a look in ~/Library/Containers to see the Apple equivalent.
- kaba0 2y ago
  It’s not about backdoors. A good chunk of linux userspace is written in unsafe languages (IMO, for no good reason). A well-intentioned buggy program opening bad-intentioned data is enough to cause trouble, and for some reason, no one seems to care about it at all. Linux distros has no security whatsoever, by any practical definition.
- codedokode 2y ago
  > there have only ever been a tiny number of backdoored open source packages First, these packages might contain vulnerabilities, second, I want to be able to run also third-party software including closed-source software, Windows software and random scripts from Github. If you restrict yourself to official repositories, then you cannot do much useful work. > consider Fedora using SELinux. Because SELinux is not what I want. I want a GUI with checkboxes like "Allow playing sound" or "Allow reading CPU model" rather than describing access to every individual file.
- microtonal 2y ago
  Linux has lots of sandboxing features. The issue is often not the individual features, but delivering them as a consistent, usable package. Though Flatpak is getting there, but it's a long road, you don't just need some kernel sandboxing features, but also toolkit extensions to make files available to sandboxed applications (portals), etc. Many Linux distros only use them minimally because the value proposition is poor: Most distros don't ship closed-source applications That's kind of putting your head in the sand. A lot of users need closed-source applications for work, such as Slack, Zoom, Chrome, Obsidian, JetBrains IDEs (the non-open source flavors), or for fun (Games, Steam, Spotify). Some have web apps, but the generally work less well. a tiny number of backdoored open source packages Backdoored applications are not the only issue. Also non-backdoored applications with vulnerabilities, basically any client, etc. The saving grace of the Linux desktop is that it's not much of an interesting target due to relatively low popularity. Otherwise actors would be hunting for vulnerabilities in RSS readers, chat clients, etc. (remember that the surface is not only the application itself, but also any image/video decoding libraries, etc.). OTOH, sandboxing tends to break the kind of complex workflows that users are fond of. That's an issue, especially for Linux power users. For most users, sandboxing can be done without too many issues (see e.g. sandboxed Mac apps).
rustcleaner 2y ago
Security is in terrible shape. Right now for power-consumers the most secure OSes for access control are GrapheneOS (AOSP) and Qubes OS. Windows (with privsep) and desktop Linux are (were) good at stopping drive-by printer driver installs but terrible at keeping your browser running rogue glowware exfiltrating blackmail to use against you (or planting felony charges to leverage). Qubes puts everything in boxes and you keep the spam and ham in separate boxes, and Graphene gives you Android's use of SELinux as well as Storage Scopes (it's like unveil()).
- Borealid 2y ago
  I wish I could use Graphene without needing to buy into their anti-OSS stance and ideology, though. The core idea is sound, but I frequently see: - MicroG is "insecure" because it requires "signature spoofing" (reality: LineageOS allows only MicroG to replace only Google Play Services - I wouldn't consider that "insecure" and the Graphene devs never explain further) - Open source software is less secure than closed source software (reality: mixed bag) - F-Droid is "insecure" (I can't address this one because I don't understand the point of view and I've never seen it clarified) - GrapheneOS executes Google Play Services in a "sandbox without any special permissions" (reality: there is a repository full of code that allows sandboxed Google Play to behave in a way other apps can't within the sandbox) - Automatically installing updates is necessary to "be secure" (reality: updates might add or remove vulnerabilities. Failing to update when a vulnerability exists is insecure, but updating automatically is not a clear win for a savvy, aware user) - System backups are not a part of a security policy (reality: having the ability to restore a backup is necessary to mitigate damage caused by an exploit) - Pixel devices are the only "sufficiently secure" phones (reality: it might be convenient targeting a single platform, but there are plenty of phones now that provide the technical capabilities Graphene requires) - Privacy is not part of security (reality: security is classic CIA - Confidentiality, Integrity, Availability. If you can't keep confidentiality you're missing one of the pillars) - Complying with Google's Compatibility Test Suite is "more secure" than deviating from it (reality: the CTS is designed to favor app developers over end users. The app developers might or might not be better at looking out for users' interests than the users themselves) Everything I'm representing as a GrapheneOS dev position I've heard straight from the horse's mouth on their forum and/or in their documentation. I think sometimes they hold opinions which aren't 100% aligned with what I'd consider a maximally secure system. That said, they have delivered a pretty solid OS if you can live with its various compromises. The one that really grates on me is the last one: I don't want an OS that chooses an app developer's "don't copy this file" flag over my desire to copy it! EDIT: formatting

cherryteastain 2y ago

Linux is a kernel. Let alone sandboxing, it does not even have an init process or bootloader by default. You can install all the utilities expected of a modern desktop OS if you want, and most distros will do it for you.

striking 2y ago

Not every app needs to be run with "full privileges" (or "as root" as some might call it), but it does usually end up being a binary decision on most distros if you're not careful. Either it can change everything or it can only affect the entire user profile it's running under. Bwrap and friends allow you to do a lot of extra isolation and get much more granular, but non-root console-only apps are generally safe to run (and safer still to run under their own user instead of yours).

yjftsjthsd-h 2y ago

Linux has lots of sandboxing features. Many Linux distros only use them minimally because the value proposition is poor: Most distros don't ship closed-source applications and in the last 30 years there have only ever been a tiny number of backdoored open source packages. OTOH, sandboxing tends to break the kind of complex workflows that users are fond of. Another angle to point out is that some distros do bake in more protective features; consider Fedora using SELinux. Then, again, keep considering SELinux and observe how many things it breaks the moment you set a single foot off the trodden path.

mike_hearn 2y ago
The Linux sandboxing features are mostly quite poor tbh. Compare to Apple's stack (if you include the private SBPL) and it doesn't come close. Apple is way ahead of both Windows and Linux when it comes to pervasive sandboxing.
- yjftsjthsd-h 2y ago
  I'm not super familiar with Darwin, but I am skeptical on the grounds that macOS doesn't have containers, which are constructed from the same primitives as a sandbox.
  - mike_hearn 2y ago
    It does indeed have something similar to containers, built on their sandboxing tech rather than namespaces. Take a look in ~/Library/Containers to see the Apple equivalent.
kaba0 2y ago
It’s not about backdoors. A good chunk of linux userspace is written in unsafe languages (IMO, for no good reason). A well-intentioned buggy program opening bad-intentioned data is enough to cause trouble, and for some reason, no one seems to care about it at all. Linux distros has no security whatsoever, by any practical definition.
codedokode 2y ago
> there have only ever been a tiny number of backdoored open source packages First, these packages might contain vulnerabilities, second, I want to be able to run also third-party software including closed-source software, Windows software and random scripts from Github. If you restrict yourself to official repositories, then you cannot do much useful work. > consider Fedora using SELinux. Because SELinux is not what I want. I want a GUI with checkboxes like "Allow playing sound" or "Allow reading CPU model" rather than describing access to every individual file.
microtonal 2y ago
Linux has lots of sandboxing features. The issue is often not the individual features, but delivering them as a consistent, usable package. Though Flatpak is getting there, but it's a long road, you don't just need some kernel sandboxing features, but also toolkit extensions to make files available to sandboxed applications (portals), etc. Many Linux distros only use them minimally because the value proposition is poor: Most distros don't ship closed-source applications That's kind of putting your head in the sand. A lot of users need closed-source applications for work, such as Slack, Zoom, Chrome, Obsidian, JetBrains IDEs (the non-open source flavors), or for fun (Games, Steam, Spotify). Some have web apps, but the generally work less well. a tiny number of backdoored open source packages Backdoored applications are not the only issue. Also non-backdoored applications with vulnerabilities, basically any client, etc. The saving grace of the Linux desktop is that it's not much of an interesting target due to relatively low popularity. Otherwise actors would be hunting for vulnerabilities in RSS readers, chat clients, etc. (remember that the surface is not only the application itself, but also any image/video decoding libraries, etc.). OTOH, sandboxing tends to break the kind of complex workflows that users are fond of. That's an issue, especially for Linux power users. For most users, sandboxing can be done without too many issues (see e.g. sandboxed Mac apps).

rustcleaner 2y ago

Security is in terrible shape. Right now for power-consumers the most secure OSes for access control are GrapheneOS (AOSP) and Qubes OS. Windows (with privsep) and desktop Linux are (were) good at stopping drive-by printer driver installs but terrible at keeping your browser running rogue glowware exfiltrating blackmail to use against you (or planting felony charges to leverage). Qubes puts everything in boxes and you keep the spam and ham in separate boxes, and Graphene gives you Android's use of SELinux as well as Storage Scopes (it's like unveil()).

Borealid 2y ago
I wish I could use Graphene without needing to buy into their anti-OSS stance and ideology, though. The core idea is sound, but I frequently see: - MicroG is "insecure" because it requires "signature spoofing" (reality: LineageOS allows only MicroG to replace only Google Play Services - I wouldn't consider that "insecure" and the Graphene devs never explain further) - Open source software is less secure than closed source software (reality: mixed bag) - F-Droid is "insecure" (I can't address this one because I don't understand the point of view and I've never seen it clarified) - GrapheneOS executes Google Play Services in a "sandbox without any special permissions" (reality: there is a repository full of code that allows sandboxed Google Play to behave in a way other apps can't within the sandbox) - Automatically installing updates is necessary to "be secure" (reality: updates might add or remove vulnerabilities. Failing to update when a vulnerability exists is insecure, but updating automatically is not a clear win for a savvy, aware user) - System backups are not a part of a security policy (reality: having the ability to restore a backup is necessary to mitigate damage caused by an exploit) - Pixel devices are the only "sufficiently secure" phones (reality: it might be convenient targeting a single platform, but there are plenty of phones now that provide the technical capabilities Graphene requires) - Privacy is not part of security (reality: security is classic CIA - Confidentiality, Integrity, Availability. If you can't keep confidentiality you're missing one of the pillars) - Complying with Google's Compatibility Test Suite is "more secure" than deviating from it (reality: the CTS is designed to favor app developers over end users. The app developers might or might not be better at looking out for users' interests than the users themselves) Everything I'm representing as a GrapheneOS dev position I've heard straight from the horse's mouth on their forum and/or in their documentation. I think sometimes they hold opinions which aren't 100% aligned with what I'd consider a maximally secure system. That said, they have delivered a pretty solid OS if you can live with its various compromises. The one that really grates on me is the last one: I don't want an OS that chooses an app developer's "don't copy this file" flag over my desire to copy it! EDIT: formatting