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.
Homebrew isn't standard package management on macOS. It's an aftermarket mod that Apple didn't have any design input to at all, and which largely imports the laissez-faire Linux approach to packaging to an OS that has a totally different design for native apps.
> 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.
It should be the other way around. I'd be extremely careful before allowing anyone to manage prod from anything other than a Mac. Apple has an OS design that can be solve many serious supply chain and credential stealing attacks. SREs don't use it today, and Apple only focuses on consumer use cases so they aren't going to use it to solve server management problems. I think there's a business opportunity in fixing that. But Apple has put in place all the infrastructure you need, whereas the Linux community simply hasn't.
> 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.
The obvious difference is that you have to create that other user (as opposed to denying the ~/Documents request). Also when you curl|bash you normally want to install under current user -- not something you're supposed to do on Linux.
I don't actually believe that macOS protects me here, as I granted this permission to the terminal five years ago...
> 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.
I need to write a proper introduction to macOS security because this thread has lots of incorrect assumptions about it!
macOS doesn't determine once whether Word can read all your documents. That's the sort of policy that applies to non-native Mac apps. Word is a native Mac app built according to Apple's design specs. Like the rest of the Office suite it opts into the stronger "app sandbox" feature macOS offers. That means:
1. It can only read files that the user granted specific access to by opening them with the system file picker. This grant is persistent across app restarts, upgrades and file moves, but is fine grained.
2. Its own files are protected against tampering from other apps. That means not just the app's binaries (which are protected in all cases regardless of app opt in), but also its own data files stored in $HOME too, like download caches. Obviously its address space is fully protected from debugging APIs too.
So if Word is compromised by a macro virus or buffer overflow, or whatever, that code is very constrained. It can't steal your SSH keys. It can't tamper with your ~/.bashrc. It can't tamper with your operating system, or escalate to root, or phish any credentials from you. Despite that, Word has all the functionality users expect.
Additionally, if you download and run malware, that malware can't edit the configuration of Word to inject macros, and if you store files in Word's protected area they can't even read those files.
MacOS only falls back to coarse grained permissions for looking at certain sub-folders of $HOME when apps bypass the native Cocoa APIs, e.g. by using open() and readdir() directly. This usually means some dev tool or script that was written with Linux in mind.
All this is possible because the kernel has very sophisticated support for app identity and security. It's exactly what you're asking for, and what Linux has failed to provide. You can open a file in Word thus granting Word access to it without even realizing you're doing it, then upgrade or downgrade Word without it losing access, move those files around, move Word around, download a beta version from some internal MS server and have two versions installed at once, etc. It's all possible because of sophisticated kernel level support working in close tandem with a lot of userspace infrastructure which is missing on Linux.
Re: entitlements. Apple's system allows entitlements to be self-declared, or granted by Apple, or both, or granted by non-Apple authorities if the OS is so configured (this latter fact is documented but obscure). MDM, app stores and anti-malware systems exploit entitlements aggressively to understand what apps can do. Their system allows a pretty complex ecosystem to develop where users can delegate trust as much or as little as they like.
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!
Documents containing scripts are genuinely useful, as are, say, Python programs.
A python program isn't a word document
People write real software using Microsoft Office's scripting features. Sure, it's not "cool" the way that Python is cool, but it works.
And neither Microsoft nor Python has a credible security model.
They shouldn't be able to do that, because it's a huge security hole.