8 ms·

Linux isn't like macOS, it doesn't have any kind of proper desktop sandboxing architecture that really works. So this is kind of security theatre. If you run a

Linux isn't like macOS, it doesn't have any kind of proper desktop sandboxing architecture that really works. So this is kind of security theatre. If you run a malicious program it can do stuff like tamper with your PATH or exploit local vulns in apps to get to the point where it can control anything that matters (which root generally doesn't). For instance it can just drop a custom shell into ~/.bin/.hidden-shell and reconfigure the terminal emulator to run it. So this kind of "vulnerability" doesn't seem that important. If you run code as yourself on Linux it owns you. On macOS it's very different. Pervasive code signing gives all apps a stable identity enforced by the kernel that they can't easily escape. The kernel can then impose sandboxing policies on any app that's run regardless of how it's installed, for instance, preventing apps from rummaging through ~/Documents or monitoring your screen. Permissions are editable and guaranteed to stick, including across upgrades. And root is disempowered so obtaining it barely matters, it's only really there for UNIX compatibility. Unfortunately implementing an Apple style architecture on Linux would be very difficult.

bigyabai 1mo ago
> it doesn't have any kind of proper desktop sandboxing architecture that really works. Bubblewrap works.
- graemep 1mo ago
  and Firejail
  - oever 1mo ago
    and sydbox
- mike_hearn 1mo ago
  Bubblewrap is a less powerful version of sandbox-exec, but the macOS architecture is much larger than just that. In effect macOS runs everything under bubblewrap, in such a way that users don't notice but apps are meaningfully sandboxed and root exploits barely matter.
  - bigyabai 1mo ago
    [flagged]
    - mike_hearn 1mo ago
      Bubblewrap isn't a sandboxing architecture, so no. Go look at how Apple designed the macOS/iOS security system and you'll see that a Bubblewrap like tool is only. small portion of it.
      - bigyabai 1mo ago
        Linux in-general is a small portion of the Darwin architecture. One is a monolithic kernel, the other has microkernel IPC security to consider. Are there any glaring limitations in Bubblewrap you'd like to point out, or are we having the Tannenbaum argument all over again?
        mike_hearn 1mo ago
        The main thing Linux lacks is any notion of app identity more sophisticated than a file path. On Darwin-based systems you can take a binary from anywhere. Downloaded into $HOME, found in /Applications, on a USB stick, network drive, app store run by Apple, app store run internal to your enterprise, doesn't matter. When you run it, the kernel computes an unforgeable identity for that program. That identity is then used for all sorts of things. It's used to: 1. Stop other apps tampering with the app's files or address space. 2. Let users grant permissions to that app via normal UI interactions. Not just to files but for anything you see in the privacy section of Settings. 3. Allow the app to upgrade itself while keeping its permissions. This doesn't require the app to use any specific package manager or update mechanism, the kernel doesn't care. 4. Allow you to run multiple versions of the app, while keeping its permissions. 5. Block the app if it's malware and make the block actually stick i.e. polymorphic code doesn't help. 6. Do an ahead of time virus scan on Apple's servers, so you get the benefits of antivirus without needing to run resource piggy scanners locally that trash performance. 7. Give the app a private file space that's protected from all other apps, where it can store configs, caches and other sensitive files. So if someone does run malware, it's very limited in how much tampering it can do. 8. Nothing depends on escalating to root, or any admin user, at any point. Linux has a much weaker system, it's nearly non-existent. 1. Programs are identified based on where their binaries are, not what their binaries are. This is totally wrong and creates a lot of problems, e.g. the same program run from $HOME vs /usr is perceived as being a totally different app by the OS. 2. Programs aren't run under bubblewrap by default in any distro I've heard of. Indeed they can't be because the kernel doesn't have any support for this. 3. Bubblewrap isn't integrated with ELF so there's no way for a binary to declare what permissions it needs. Contrast with: `codesign --display --entitlements :- /Applications/Microsoft\ Word.app | xmllint --format -` which tells you what permissions Word has when it runs. 4. Desktop environments struggle to implement the PowerBox pattern macOS relies on so much, because desktop APIs are too fragmented on Linux and most common apps ignore them in favour of rolling their own equivalents. So bubblewrap by itself can't make sandboxing transparent. FlatPak is trying to implement a PowerBox design with portals, but it's obviously a layer above Bubblewrap alone.
Retr0id 1mo ago
> Unfortunately implementing an Apple style architecture on Linux would be very difficult. On desktop Linux as we know it, yes, but Android manages it alright, mostly via SELinux+seccomp.
- mike_hearn 1mo ago
  Android is basically a different OS that happens to reuse parts of the Linux kernel.
  - Retr0id 1mo ago
    Yes, it reuses all the security features.
    - 2OEH8eoCRo0 1mo ago
      Doesn't each app run as it's own user? The OG of security features.
    - mike_hearn 1mo ago
      It respins UNIX security in favour of a mix of SELinux and a (mis-)use of UNIX user/group identities to contain apps instead of users. Linux distros sort of do that too but only for system services, whereas Android does it for user visible apps.
amluto 1mo ago
> Linux isn't like macOS, it doesn't have any kind of proper desktop sandboxing architecture that really works. I’m sorry, what? MacOS’s desktop sandboxing is pathetic. Sure, it kind of sort of tries to prevent an application from rummaging until you give it permission. And that permission is hilariously coarse grained, and it gets regularly broken anyway. (Seriously, read about TCC breaks. They’re not little implementation errors — they’re giant gaping holes in the whole concept.) The entitlement mechanism basically serves to help Apple restrict what developers can do without meaningful protecting Apple’s users. If you think that it protects you when your Mac prompts to ask whether Terminal.app may access Documents, you are welcome to enjoy your warm fuzzy feelings. > Unfortunately implementing an Apple style architecture on Linux would be very difficult. Why would it be difficult? I think that mostly it would reveal to whomever implemented it how useless it is. If you mean sandbox-exec, you can do this on Linux, too. And the Linux mechanisms are not considered deprecated and undocumented, whereas Apple steadfastly refuses admit that sandbox-exec is a real mechanism.
- mike_hearn 1mo ago
  There can be exploits in any security system but the architecture is sound. There's no equivalent of TCC on Linux (I mean one that really sticks), and no easy way to create one. The sandboxing isn't bad. It's obviously weaker if you do everything in the Terminal and stay in old-school UNIX territory because it wasn't designed to sandbox developer workloads. But it's a lot better than nothing, which is what Linux offers. The OS does actually protect you when it asks if the terminal should be able to access ~/Documents. You can say no, and then random stuff you curl|bash can't read files in that folder unless there's an exploit. Apps that opt in to app sandboxing are much better protected and can store files/settings in an area of $HOME that other apps can't access at all without the right permissions. It would be difficult to do on Linux because an Apple style architecture requires apps to systematically use the blessed OS APIs for functionality. Not only for things like file pickers but also camera access, storing preferences, etc. In Linux it'd require the architecture to be tied to a specific desktop environment and associated set of apps. There's not enough consistency otherwise. It also needs pervasive kernel enforced app identity and equivalents to Apple's bookmarks, Mach context propagation, SBPL, app containers architecture etc. It also needs an agreed on way to handle malware reporting and detection, out of the box, and some authority that's trusted to hand out sensitive permissions (for writing debuggers, if nothing else). You can hack something together with bits and pieces Linux has, and define a way to write apps that delivers something like Apple's architecture - as Android has - but that won't bring the ecosystem with you. And it will suffer from a high degree of centralization where distributors have to approve every app, with any app you get outside your distro's package repositories being a free for all. Apple's architecture allows apps to be distributed outside the app store while still being sandboxed to a lesser or greater extent, as well as scanned for malware ahead of time and located anywhere on disk (by extension, you can have >1 version of an app installed at once and sandboxing still works).
Cloudef 1mo ago
Its opposite. Windows and MacOS lacks proper sandboxing. While openbsd has pinsyscalls and linux has seccomp-bpf. Windows and MacOS only have filesystem and worse version of user namespace sandboxes, anything else and you need to write a kernel extension or rely on a hypervisor. > Unfortunately implementing an Apple style architecture on Linux would be very difficult. The apple apps kind of thing already exists and its called flatpak.
- oneplane 1mo ago
  Windows has virtualisation based sandboxing and NT has object-level security (albeit not often used correctly and granularly) and macOS has (among other things) SIP and a subsystem called sandbox that does exactly what it says: it sandboxes. It can sandbox in comparable namespace terms (like cgroups v1 or v2, but more in translocation style execution since it's a MAC framework) yet it also does it a much more fine-grained level depending on what you need. It is used by launchd and applications by default, some entitlements require it so if you want to do some broad kind of elevated application, you also have to have a specific sandbox profile. It's also been around for 16 years, and comes with a ton of examples if you wanted to use it yourself to constrain some process. Yes, it can do filesystem (would be pointless without it), but also does ipc, io, network, memory, fcntl, sysctl, mach ports, sys calls, processes, ui, sockets, messaging, events and all of that including context-aware filtering and compound matching for all of them. And if that's not enough there is also ESF and NEF, the latter only working on networking. You can compare those two to eBFP LSM and XDP. If you want all of this on linux, you'll need to add a lot of custom eBPF and LSM as well as always run in a hypervisor for guaranteed IOMMU usage, but you can't use bare KVM for that either, so you'll either need to never touch the privileged kernel (not even give it a console) or you need to run Xen and use XSM. Flatpak is just a cheap container copy. Can't do anything beyond what cgroups and things like apparmor and selinux can do, and uses a runtime to do soft higher-level policy functions that translate down to the same primitives. If anything, it's a great bundler, but doesn't do anything new policy-wise. So, can you get the macOS-level capabilities (both low-level and higher abstractions)? On Linux, yes, but they don't exist yet. On Windows: technically possible, but since that would break most GUI workflow it's not likely that anyone is going to bother, and you're going to have a hard time recompiling windows yourself to make that happen.
lrvick 1mo ago
> Linux isn't like macOS, it doesn't have any kind of proper desktop sandboxing architecture that really works. As a QubesOS user, I beg to differ. Just because most Linux distros are negligent with sandboxing does not mean all of them are.
- veeti 1mo ago
  Funny because there is a 101 level Qubes RCE on front page right now.
  - literalAardvark 1mo ago
    Eh. That happens sometimes, but its design and track record is really good.
  - lrvick 1mo ago
    Sigh. Qubes had some great security design and implemented it the only way time/funds would allow: by cobbling together a lot of unfortunately very complex and broken things built for a different security model decades ago. Qubes is the least bad option for laptops (until Stagex Work ships which I am designing) but there is no reasonable server OS. I am ripping off the best ideas from xen/Qubes and starting over with: https://distrust.co/blog/enclaveos.html https://distrust.co/blog/enclaveos.html
- negura 1mo ago
  what are you on about? The fact Qubes has to exist proves Linux is insecure. QubesOS is not a Linux distro. It just happens to ship dom0 as a Fedora VM. But it doesn't just support Linux, it also supports Windows and BSDs. None of Qubes security guarantees come from the Linux kernel.
  - deleted 1mo ago
    [deleted]
rixed 1mo ago
The issue is not that Linux lacks a central authority that holds some encryption keys and controls what software you can run. The issue is that you should not run any software from a source that can't be trusted. When we used to run only software from community distros or that we compile ourselves, launching a malicious program was a non issue.

bigyabai 1mo ago

> it doesn't have any kind of proper desktop sandboxing architecture that really works. Bubblewrap works.

graemep 1mo ago
and Firejail
- oever 1mo ago
  and sydbox
mike_hearn 1mo ago
Bubblewrap is a less powerful version of sandbox-exec, but the macOS architecture is much larger than just that. In effect macOS runs everything under bubblewrap, in such a way that users don't notice but apps are meaningfully sandboxed and root exploits barely matter.
- bigyabai 1mo ago
  [flagged]
  - mike_hearn 1mo ago
    Bubblewrap isn't a sandboxing architecture, so no. Go look at how Apple designed the macOS/iOS security system and you'll see that a Bubblewrap like tool is only. small portion of it.
    - bigyabai 1mo ago
      Linux in-general is a small portion of the Darwin architecture. One is a monolithic kernel, the other has microkernel IPC security to consider. Are there any glaring limitations in Bubblewrap you'd like to point out, or are we having the Tannenbaum argument all over again?
      - mike_hearn 1mo ago
        The main thing Linux lacks is any notion of app identity more sophisticated than a file path. On Darwin-based systems you can take a binary from anywhere. Downloaded into $HOME, found in /Applications, on a USB stick, network drive, app store run by Apple, app store run internal to your enterprise, doesn't matter. When you run it, the kernel computes an unforgeable identity for that program. That identity is then used for all sorts of things. It's used to: 1. Stop other apps tampering with the app's files or address space. 2. Let users grant permissions to that app via normal UI interactions. Not just to files but for anything you see in the privacy section of Settings. 3. Allow the app to upgrade itself while keeping its permissions. This doesn't require the app to use any specific package manager or update mechanism, the kernel doesn't care. 4. Allow you to run multiple versions of the app, while keeping its permissions. 5. Block the app if it's malware and make the block actually stick i.e. polymorphic code doesn't help. 6. Do an ahead of time virus scan on Apple's servers, so you get the benefits of antivirus without needing to run resource piggy scanners locally that trash performance. 7. Give the app a private file space that's protected from all other apps, where it can store configs, caches and other sensitive files. So if someone does run malware, it's very limited in how much tampering it can do. 8. Nothing depends on escalating to root, or any admin user, at any point. Linux has a much weaker system, it's nearly non-existent. 1. Programs are identified based on where their binaries are, not what their binaries are. This is totally wrong and creates a lot of problems, e.g. the same program run from $HOME vs /usr is perceived as being a totally different app by the OS. 2. Programs aren't run under bubblewrap by default in any distro I've heard of. Indeed they can't be because the kernel doesn't have any support for this. 3. Bubblewrap isn't integrated with ELF so there's no way for a binary to declare what permissions it needs. Contrast with: `codesign --display --entitlements :- /Applications/Microsoft\ Word.app | xmllint --format -` which tells you what permissions Word has when it runs. 4. Desktop environments struggle to implement the PowerBox pattern macOS relies on so much, because desktop APIs are too fragmented on Linux and most common apps ignore them in favour of rolling their own equivalents. So bubblewrap by itself can't make sandboxing transparent. FlatPak is trying to implement a PowerBox design with portals, but it's obviously a layer above Bubblewrap alone.

Retr0id 1mo ago

> Unfortunately implementing an Apple style architecture on Linux would be very difficult. On desktop Linux as we know it, yes, but Android manages it alright, mostly via SELinux+seccomp.

mike_hearn 1mo ago
Android is basically a different OS that happens to reuse parts of the Linux kernel.
- Retr0id 1mo ago
  Yes, it reuses all the security features.
  - 2OEH8eoCRo0 1mo ago
    Doesn't each app run as it's own user? The OG of security features.
  - mike_hearn 1mo ago
    It respins UNIX security in favour of a mix of SELinux and a (mis-)use of UNIX user/group identities to contain apps instead of users. Linux distros sort of do that too but only for system services, whereas Android does it for user visible apps.

amluto 1mo ago

> Linux isn't like macOS, it doesn't have any kind of proper desktop sandboxing architecture that really works. I’m sorry, what? MacOS’s desktop sandboxing is pathetic. Sure, it kind of sort of tries to prevent an application from rummaging until you give it permission. And that permission is hilariously coarse grained, and it gets regularly broken anyway. (Seriously, read about TCC breaks. They’re not little implementation errors — they’re giant gaping holes in the whole concept.) The entitlement mechanism basically serves to help Apple restrict what developers can do without meaningful protecting Apple’s users. If you think that it protects you when your Mac prompts to ask whether Terminal.app may access Documents, you are welcome to enjoy your warm fuzzy feelings. > Unfortunately implementing an Apple style architecture on Linux would be very difficult. Why would it be difficult? I think that mostly it would reveal to whomever implemented it how useless it is. If you mean sandbox-exec, you can do this on Linux, too. And the Linux mechanisms are not considered deprecated and undocumented, whereas Apple steadfastly refuses admit that sandbox-exec is a real mechanism.

mike_hearn 1mo ago
There can be exploits in any security system but the architecture is sound. There's no equivalent of TCC on Linux (I mean one that really sticks), and no easy way to create one. The sandboxing isn't bad. It's obviously weaker if you do everything in the Terminal and stay in old-school UNIX territory because it wasn't designed to sandbox developer workloads. But it's a lot better than nothing, which is what Linux offers. The OS does actually protect you when it asks if the terminal should be able to access ~/Documents. You can say no, and then random stuff you curl|bash can't read files in that folder unless there's an exploit. Apps that opt in to app sandboxing are much better protected and can store files/settings in an area of $HOME that other apps can't access at all without the right permissions. It would be difficult to do on Linux because an Apple style architecture requires apps to systematically use the blessed OS APIs for functionality. Not only for things like file pickers but also camera access, storing preferences, etc. In Linux it'd require the architecture to be tied to a specific desktop environment and associated set of apps. There's not enough consistency otherwise. It also needs pervasive kernel enforced app identity and equivalents to Apple's bookmarks, Mach context propagation, SBPL, app containers architecture etc. It also needs an agreed on way to handle malware reporting and detection, out of the box, and some authority that's trusted to hand out sensitive permissions (for writing debuggers, if nothing else). You can hack something together with bits and pieces Linux has, and define a way to write apps that delivers something like Apple's architecture - as Android has - but that won't bring the ecosystem with you. And it will suffer from a high degree of centralization where distributors have to approve every app, with any app you get outside your distro's package repositories being a free for all. Apple's architecture allows apps to be distributed outside the app store while still being sandboxed to a lesser or greater extent, as well as scanned for malware ahead of time and located anywhere on disk (by extension, you can have >1 version of an app installed at once and sandboxing still works).

Cloudef 1mo ago

Its opposite. Windows and MacOS lacks proper sandboxing. While openbsd has pinsyscalls and linux has seccomp-bpf. Windows and MacOS only have filesystem and worse version of user namespace sandboxes, anything else and you need to write a kernel extension or rely on a hypervisor. > Unfortunately implementing an Apple style architecture on Linux would be very difficult. The apple apps kind of thing already exists and its called flatpak.

oneplane 1mo ago
Windows has virtualisation based sandboxing and NT has object-level security (albeit not often used correctly and granularly) and macOS has (among other things) SIP and a subsystem called sandbox that does exactly what it says: it sandboxes. It can sandbox in comparable namespace terms (like cgroups v1 or v2, but more in translocation style execution since it's a MAC framework) yet it also does it a much more fine-grained level depending on what you need. It is used by launchd and applications by default, some entitlements require it so if you want to do some broad kind of elevated application, you also have to have a specific sandbox profile. It's also been around for 16 years, and comes with a ton of examples if you wanted to use it yourself to constrain some process. Yes, it can do filesystem (would be pointless without it), but also does ipc, io, network, memory, fcntl, sysctl, mach ports, sys calls, processes, ui, sockets, messaging, events and all of that including context-aware filtering and compound matching for all of them. And if that's not enough there is also ESF and NEF, the latter only working on networking. You can compare those two to eBFP LSM and XDP. If you want all of this on linux, you'll need to add a lot of custom eBPF and LSM as well as always run in a hypervisor for guaranteed IOMMU usage, but you can't use bare KVM for that either, so you'll either need to never touch the privileged kernel (not even give it a console) or you need to run Xen and use XSM. Flatpak is just a cheap container copy. Can't do anything beyond what cgroups and things like apparmor and selinux can do, and uses a runtime to do soft higher-level policy functions that translate down to the same primitives. If anything, it's a great bundler, but doesn't do anything new policy-wise. So, can you get the macOS-level capabilities (both low-level and higher abstractions)? On Linux, yes, but they don't exist yet. On Windows: technically possible, but since that would break most GUI workflow it's not likely that anyone is going to bother, and you're going to have a hard time recompiling windows yourself to make that happen.

lrvick 1mo ago

> Linux isn't like macOS, it doesn't have any kind of proper desktop sandboxing architecture that really works. As a QubesOS user, I beg to differ. Just because most Linux distros are negligent with sandboxing does not mean all of them are.

veeti 1mo ago
Funny because there is a 101 level Qubes RCE on front page right now.
- literalAardvark 1mo ago
  Eh. That happens sometimes, but its design and track record is really good.
- lrvick 1mo ago
  Sigh. Qubes had some great security design and implemented it the only way time/funds would allow: by cobbling together a lot of unfortunately very complex and broken things built for a different security model decades ago. Qubes is the least bad option for laptops (until Stagex Work ships which I am designing) but there is no reasonable server OS. I am ripping off the best ideas from xen/Qubes and starting over with: https://distrust.co/blog/enclaveos.html https://distrust.co/blog/enclaveos.html
negura 1mo ago
what are you on about? The fact Qubes has to exist proves Linux is insecure. QubesOS is not a Linux distro. It just happens to ship dom0 as a Fedora VM. But it doesn't just support Linux, it also supports Windows and BSDs. None of Qubes security guarantees come from the Linux kernel.
- deleted 1mo ago
  [deleted]

rixed 1mo ago

The issue is not that Linux lacks a central authority that holds some encryption keys and controls what software you can run. The issue is that you should not run any software from a source that can't be trusted. When we used to run only software from community distros or that we compile ourselves, launching a malicious program was a non issue.