Hacker News Reader

Comment by CharlesW | Hacker News Reader

> You can't just add them later, on top of the legacy Mac OS and NeXTSTEP technologies.

Apple can (and has been) since it owns the whole stack, evidenced by the fact that they've been gradually hardening macOS software and hardware for two decades.

It's been gradual enough that most end users haven't noticed, but macOS developers are painfully aware of the security-related issues they have to reckon with in both major and minor updates to macOS. Example:

  https://eclecticlight.co/2024/08/27/launching-apps-in-sonoma-14-6-1-full-security/
  https://eclecticlight.co/2024/08/28/launching-apps-in-sonoma-14-6-1-reduced-security/
  https://eclecticlight.co/2024/08/29/launching-apps-in-sonoma-14-6-1-known-malware/
  https://eclecticlight.co/2024/09/03/launching-apps-in-sonoma-14-6-1-conclusions/

View on HN

> Apple can (and has been) since it owns the whole stack, evidenced by the fact that they've been gradually hardening macOS software and hardware for two decades.

This is kind of an empty reply. Of course Apple can try and has been trying. The question is whether they can do it successfully, and I would argue it hasn't been successful.

> It's been gradual enough that most end users haven't noticed

This is not true at all. Users have definitely noticed all of the permissions dialogs and other related settings.

> The question is whether they can do it successfully, and I would argue it hasn't been successful.

Security has no finish line, unfortunately. But here are a few security-related things Sequoia has that Mac OS X 10.0 did not:

A firewall. VPN support. FileVault and FileVault 2. Secure Empty Trash. Increasingly-secure sandboxing. Library randomization. Address Space Layout Randomization. XProtect. Increasingly-secure versions of Gatekeeper. Increasingly-secure memory management. SIP. Kernel exploit mitigations. New update mechanisms for security patches. APFS and its associated security improvements. Notarization. Read-only system volume. Separation of user data and system files. Activation Lock. Improved system logging and auditing. Signed System Volume. Private Relay. Lockdown Mode. Visual indicators of mic/camera/location use. DriverKit to replace the use of kexts. Secure Enclave for hardware-based root of trust and secrets management.

I'm just someone who pays attention. I imagine actual security experts could list 20+ other improvements off the top of their head.

A number of those are security theater, and some of them aren't even for security at all. Also, the secure empty trash feature was actually removed from macOS, and I'm not sure what you mean by the "associated security improvements" of APFS.

But it's not even a question of whether security has a "finish line". The question is whether a specific security feature works on not, and some of them just don't work.

> Security has no finish line, unfortunately.

Unfortunately? Unfortunately!

I beg your pardon. Apple's service revenue is very fortunate for the neverending excuse of security. Want third-party payment processors? It's not that it would upset our revenue stream, it's just too insecure. You want to sideload with the flick of a switch? It's not like we already offer that feature to other users of our products and paying developers, it's not secure enough to attempt. Want an open bootloader for your iPhone like those Apple Silicon Macs? It's not that Apple can't do it, it's just that they claim it's not secure enough.

The real kicker? None of us have a privileged enough view of the ecosystem to even know if Apple is right or not. The fact that security has no finish line should be carefully construed as not to excuse companies that move the goalposts of security for petty means. Apple is grateful that customers will accept "security" as a carte-blanche answer to completely unrelated topics.

Every year I battle with a few permission related bugs in my app. Somehow macOS will randomly block some file accesses on some machines in some circumstances.

Take security scoped bookmarks. The only way that sandboxed apps can persistently access files outside their sandbox. It's an important feature. It's broken on some Macs. I know from logs that about 0.5% of my users run into this bug. It's been broken for years, and every time I report the problem to Apple they ask me for steps to reproduce or and Xcode sample project. I have no idea what to do, it's a bug in ScopedBookmarkAgent or in SecKeychain somewhere.

With Sequoia, they managed to break the feature for about 10% of users. That was apparently enough to get Apple to pay attention, so they fixed it in macOS 15.1. I think it's back to 0.5% now.

Somehow Apples own apps aren't affected by these bugs. Bugs that mostly affect 3rd party apps seem to slip through a lot more easily.

The security tech in macOS is unreliable garbage. And people praise it, they just think 3rd party apps are buggy. But for a lot of my bugs, the bug is in the macOS frameworks, but users come to me and complain.

It's no wonder that many developers don't sandbox their apps. It's just perpetually broken.

I wish they would make their tech reliable.

There's a global limit on the number of sandbox extensions (security scoped bookmarks) open at once. If it fails that's because someone is leaking them.

Hitting the sandbox extension limit is not necessarily a leak. There are a number of apps that deal with thousands of files at once and they will very quickly hit the limits. It's a perennial problem with anyone who makes professional, but sandboxed, software for macOS.

Yes, I should've said "can be". They are definitely difficult to manage. It doesn't help that people like to pass file paths or URLs across IPC and don't think of eg sending file descriptors over directly.

Hmm, who needs thousands of files at once (as opposed to serially)?

Interesting. Maybe that's one of the reasons. I think there are multiple root causes. Another common issue I see is "failed to get app specific key"

Reply on news.ycombinator.com