5 ms·

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 w

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).

lrvick 1mo ago
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.
- mike_hearn 1mo ago
  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 maximally exploit 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.
  - lrvick 1mo ago
    > It's an aftermarket mod Unfortunately one I have never seen a MacOS production engineering guide that does not say "install brew" as like step one, exactly because Apple failed to provide a software suite sufficient to meet developer needs on par with that of major linux distributions. Macports is at least maintained by current/former apple employees and signs their packages, but in practice no one knows macports exists. > I'd be extremely careful before allowing anyone to manage prod from anything other than a Mac. I would never even consider letting anyone near production Linux servers if they are not comfortable enough to maintain and secure Linux on the computer in front of them. > I think there's a business opportunity in fixing that. Me too! I am in the current YC batch for exactly that reason with https://caution.co https://caution.co , built with https://stagex.tools https://stagex.tools.
    - mike_hearn 1mo ago
      Ah, neat. I did something like Caution a few years ago but for Intel SGX, called Conclave. It made it much easier to deploy apps to enclaves, get remote attestations and communicate with them securely. Unfortunately it's a difficult space to work in. SGX tries to remove the kernel and hardware from the TCB but there are a lot of obscure attacks to do with tampering with the enclave's sense of time. It's not an SGX problem, it's inherent to enclaves not having enough trusted hardware like signed clocks, tamper-resistant counters and so on. Also the programming model has to be adapted but most customers just want a button to click for a box to tick, then they can say they're protected. Very few want to change their app architecture to be more secure. Homebrew is far from ideal, indeed, but MacOS was never really marketed as an OS for people to manage remote server clusters. If you stick within their designed ecosystem and only do software dev for native Apple desktop/mobile apps using XCode, then you don't need homebrew.
amluto 1mo 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.
- inigyou 1mo ago
  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!
  - amluto 1mo ago
    Documents containing scripts are genuinely useful, as are, say, Python programs.
    - 1mo ago
drnick1 1mo 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. 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.
- asqueella 1mo ago
  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...

lrvick 1mo ago

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.

mike_hearn 1mo ago
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 maximally exploit 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.
- lrvick 1mo ago
  > It's an aftermarket mod Unfortunately one I have never seen a MacOS production engineering guide that does not say "install brew" as like step one, exactly because Apple failed to provide a software suite sufficient to meet developer needs on par with that of major linux distributions. Macports is at least maintained by current/former apple employees and signs their packages, but in practice no one knows macports exists. > I'd be extremely careful before allowing anyone to manage prod from anything other than a Mac. I would never even consider letting anyone near production Linux servers if they are not comfortable enough to maintain and secure Linux on the computer in front of them. > I think there's a business opportunity in fixing that. Me too! I am in the current YC batch for exactly that reason with https://caution.co https://caution.co , built with https://stagex.tools https://stagex.tools.
  - mike_hearn 1mo ago
    Ah, neat. I did something like Caution a few years ago but for Intel SGX, called Conclave. It made it much easier to deploy apps to enclaves, get remote attestations and communicate with them securely. Unfortunately it's a difficult space to work in. SGX tries to remove the kernel and hardware from the TCB but there are a lot of obscure attacks to do with tampering with the enclave's sense of time. It's not an SGX problem, it's inherent to enclaves not having enough trusted hardware like signed clocks, tamper-resistant counters and so on. Also the programming model has to be adapted but most customers just want a button to click for a box to tick, then they can say they're protected. Very few want to change their app architecture to be more secure. Homebrew is far from ideal, indeed, but MacOS was never really marketed as an OS for people to manage remote server clusters. If you stick within their designed ecosystem and only do software dev for native Apple desktop/mobile apps using XCode, then you don't need homebrew.

amluto 1mo 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.

inigyou 1mo ago
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!
- amluto 1mo ago
  Documents containing scripts are genuinely useful, as are, say, Python programs.
  - 1mo ago

drnick1 1mo 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. 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.

asqueella 1mo ago
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...