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.
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.
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.
macOS absolutely has sandboxing, what are you talking about? But the reality is that you need custom sandboxing tools less when you don't have basic problems like "anything that runs ever can read my ~/.ssh directory without problem" or "you can hijack my password by interposing sudo and thus do anything". This does not matter because macOS will see a program signed by Corp XYZ is trying to read data not owned by that cryptographic signature, and it can't escape the code signature check, and it will flag it. A program cannot simply read your password from stdin and elevate privileges silently, because granting new privileges requires communicating with a higher privilege program so it can delegate to you, and that program has a non spoofable prompt. And so on.
You can use Linux's sandboxing functionality to make a pretty hardened server. If you take in mind the physical deployment and go the extra mile, it can be very secure. The Linux desktop is not and will never be secure in its current form from things like extremely basic local malware. You would have to redesign much of the desktop stack from the init system downward so you could easily do things signature-based identity, proper per-identity secure storage and key management, securitizing elevation of privileges, getting rid of setuid, etc.
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.
> 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.
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).
Mac users always like to defend some of the things Apple legitimately got right over most Linux distros, but always ignore that supply chain security and standard package management security on Apple (Homebrew) is akin to giving a bunch of internet randos root access to your machine with no oversight, vetting, or code review of any kind. At least most Linux distros do basic package signing.
Someone even thinking it is reasonable to try to use a mac to manage production would be grounds for me to ensure they never have production access.
Also, QubesOS is a thing, therefore QubesOS Linux users have way way better access to sandboxing than MacOS -and- signed devtools packages.
> 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.
If you say no, you can’t use less or cat to read your documents. If you say yes then you are completely unprotected, forever, from anything you might run from the terminal.
> It also needs pervasive kernel enforced app identity
Doing like MacOS needs app identity. But this model is just wrong, because it answers the wrong question. Determining, once, whether Microsoft Word or VSCode may access all your documents, means that any Word document, using valid scripting or an exploit against Word, may access all your documents, and it means that you are fully exposed to anything you look at in vscode (as vscode has almost no security).
The right questions would be: May this document access this file or folder? May this project access anything outside its own folder? May this Python script read your screen? May this AI agent session access this USB device? Kernel-managed app identity is completely unhelpful for any of this.
(Frankly, kernel managed app identity seems unnecessary for most of what Mac does, too. App identity could be set by whatever launches the app, so long as the app’s resulting privileges are not allowed to exceed those of the launcher.)
> And it will suffer from a high degree of centralization where distributors have to approve every app
Please elaborate.
Sure, if you actually think that an Apple-like entitlement system protects you well, then I guess that a non-Apple entitlement system would need some trusted authority to grant entitlements. I do not think it protects anyone very well even if Apple, as the entitlement granter, is considered fully trustworthy.
The right right question would be: why aren't we enforcing a document to be self-contained? Why are documents agents? Why can any document access anything or indeed, do anything? That's not a document, that's a program!
> 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.
How is that different from creating a new user to run that script? This has been the standard practice on Linux for decades, and it is how I run tools like Codex and Claude on my machine. I wouldn't allow AI tools access to files, mount points, etc, owned by my main user.
This works best for terminal apps; for GUI apps such as Steam and games where running a separate graphical session isn't practical, you can use bubblewrap.
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.
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.
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.