There's an endless stream of bypasses on macOS, because the operating system was never designed for these granular permissions. You can't just add them later, on top of the legacy Mac OS and NeXTSTEP technologies.
I've found a number of bypasses myself, and I'm not even a security researcher, just a longtime app developer. I know where the bodies are buried, so to speak. However, I ultimately gave up looking, because Apple's security vulnerability reporting system is absolute trash; their only interest seems to be to keep you quiet for as long as possible. It's a waste of time.
My overall feeling is that macOS has become the victim of security theater, harming both users and legitimate developers with enfeedbled software and an endless stream of permissions requests—much like Apple's old parody of Windows Vista—while doing nothing to stop real attackers, who can easily bypass the security theater whenever they want.
The researcher who wrote this article seems to have been able to get a lot of holes patched with credits, albeit, some of these CVEs seem years old.
I guess a company wanting as much time as possible to fix bugs is a part of the game though, are other companies really keen for you to announce found vulns ASAP? They don't control how fast people upgrade so announcing slower is always better for end users, and that must ultimately take priority over the need of researchers for publicity. Isn't this something that one has to accept when finding holes in a consumer OS as an external?
The Apple sandbox architecture seems well designed to me, usually at least. There seems to have been some breakdown in architecture or communication in this case. To the extent there are bypasses it's because we demand a lot of functionality from desktop operating systems, arguably they are the most sophisticated and complex kind of operating system out there - far more so than server platforms. Web browsers also have a lot of CVEs and it's for the same reason. We want security, but also functionality, and inevitably there's going to be a tension point in the middle where the two rub up against each other.
> The researcher who wrote this article seems to have been able to get a lot of holes patched with credits, albeit, some of these CVEs seem years old.
Yes, it requires a lot of time and patience. And I bet that the researcher has more reported vulnerabilities that he can't talk about and aren't fixed. He's been doing this for many years.
> I guess a company wanting as much time as possible to fix bugs is a part of the game though, are other companies really keen for you to announce found vulns ASAP?
Apple is notorious for poor communication with security researchers... and with developers, and with everyone else. Apple also tends to patch vulnerabilities more slowly than, say, Google, and Apple frequently stiffs people on the security bounty.
> Apple frequently stiffs people on the security bounty.
Having seen the receiving end of a bounty program of a relatively small SaaS business it's shocking to see how many people are abusing such a program with irrelevant or plain false 'vulnerabilities' and keep begging for a bounty (even when it's clearly stated it's impossible to send money to their countries).
I can't imagine how many filters Apple has to employ to just get rid of the noise and get something of value from such a program.
Said researcher has expressed basically this exact concern fwiw. Just because they’re being paid on some bugs doesn’t mean their life is all sunshine and rainbows.
Google forces upgrades on people much more aggressively than Apple does though. None of their platforms let users opt out of upgrades except Android, which is also notorious for slow patching cycles (at least historically).
> 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:
> 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.
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.
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)?
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.
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.
I think this legacy is a burden in all mainstream operating systems? There are capability-based system, but none of them have any traction.
I am not sure what the solution is. Trying to bolt on security still seems better than doing nothing at all, where an application vulnerability immediately means a compromise of the a full user account?
SELinux can be part of the solution but it doesn’t solve the problem. The median Linux system is far behind the median Mac because while SELinux exists you still have to craft fine-grained policies and deal with all of the exceptions needed to have the system still be usable. This is more a function of budget than anything else.
>> SELinux can be part of the solution but it doesn’t solve the problem
Hold on that’s changing the goalposts a bit here. SELinux doesn’t solve this problem on RHEL boxes by virtue of just existing. It is the tool that Redhat uses to solve the problem. And they have solved the problem by using this tool. To the point that for years now, by default, RH boxes are installed in enforcing mode.
>> The median Linux system is far behind the median Mac
I’m not really interested in the median because for better or worse, Redhat is the most serious game in town for SELinux. Comparing Mac to RHEL, there’s only one place where Mac is ahead and that is a default Mac install at least on Apple silicon will have an immutable root. Redhat has irons in the fire here (rpm ostree can infuturue unlock a user friendly immutable root). Of course you can do immutable root today (and immutable usr and even epehemeral var if you want), but I’m not going to argue those are user friendly. An experienced sysadmin will take a minute to flip over between immutable root file systems during an upgrade process.
>> This is more a function of budget than anything else.
Agreed, but the Apple chequebook looks plenty beefy.
> And they have solved the problem by using this tool. To the point that for years now, by default, RH boxes are installed in enforcing mode.
They’ve shipped it, yes. It doesn’t count as solved until all of the apps are running with policies which actually block attacks like this, just as having a fire extinguisher on the shelf doesn’t mean your fire is guaranteed to be out.
> Comparing Mac to RHEL, there’s only one place where Mac is ahead and that is a default Mac install at least on Apple silicon will have an immutable root.
Also they have far more common use of sandboxing for applications (including the harder bits about selective permissions for apps), code signing, memory protection, pervasive use of HSM and robust layered storage encryption, etc. – all out of the box, whereas even in the much easier case of servers you’re looking at many hours of skilled labor to configure an equivalent.
My point about budgets is that this is just a lot of work. Apple’s not perfect but a lot of people have a mental model from the 2000s which is no longer true.
>Redhat is the most serious game in town for SELinux
SELinux on Red Hat only confines web servers, DNS servers and such. All software started by an interactive user, including web browsers, runs in the "unconfined" domain (term?), which means SELinux is not even trying to contain that software.
ChromeOS OTOH does use selinux to sandbox the browser (and IIUC Android uses it to sandbox every app).
>Comparing Mac to RHEL, there’s only one place where Mac is ahead
That's not my understanding: Mac is far from perfect, but it is more secure overall than RHEL and Fedora IMO. It's not just that the Mac verifies the integrity of /usr and such whereas Linux distros do not.
Agreed, I’m not suggesting selinux itself is the solution for Apple. I’m just saying faced with the same problem, and accepting that they have different usability constraints on them (sysadmins vs potentially novice computer users), another group found a solution. Why can’t Apple - they have the money to buy the engineering resource to bottom this out.
Usability is apple’s thing. My AirPods just work, every Bluetooth headset before just annoyed. Why can’t they achieve usability in this space? To be honest, redhat’s solution is pretty darned usable - in the context of an enterprise Linux box(1). it helps that they built that database of policy profiles but even creating my own policy is pretty straightforward (3 commands + whatever it takes to make my app exercise all its code paths)
My Grandma doesn't have a need for backwards compatibility or the million other things that stop Apple from just making a new operating system.
Normal people's use cases for their computer is light file management, light document and productivity workflows and everything else is done in the browser. Hell, most of the document processing and productivity crap is in the browser these days too.
This is the real answer - 90% of people can use a phone or an iPad for their general computational needs - and the PC/Mac itself will trend toward that, with harder and harder gates to bypass to get a truly "general" computer.
Same for Windows' UAC in the Vista era, which doesn't make it bad technology or place the fault on Microsoft. The world is full of terrible development practices, the answer shouldn't be "just disable your security mechanisms".
That's rather self critical of you, even if deserved.
My grandma also can't write software, or really do anything advanced, no should she be able to. SELinux, just like any other security and/or containerization technology, is supposed to be used by developers, sysadmins, distribution maintainers. Not by end users.
Is the macos sandbox the odd one out? I'm not familiar with it, but find it very hard to believe that "my grandma" is its target audience.
You can't compare Android to macOS. Compare Android to iOS, which had many more limitations built-in from the start than macOS.
Incidentally, this is why iPad has never become the desktop replacement everyone claimed it would be. The hardware is plenty powerful, but it's always been very limited by the software. The greater freedom and capabilities of macOS is a huge advantage for desktop-class functionality.
I think I disagree. If iOS or Android added robust support for external monitors, external keyboards and pointing devices, I'd probably switch to it to get the increased resistance against attacks.
If I could continue to run Emacs, e.g., in a VM like WSL2 or Crostini, I'd probably switch right away. If not, it would take me a year or 2 to transition to a replacement before I switch (and, no, that replacement would not need to be able to run software written in Emacs Lisp: I'd be happy to replace, rewrite or walk away from any functionality I currently get from code written in Emacs Lisp).
I use Linux, I would not switch to Android, but I agree the Linux userland should take sandboxing much more seriously. Things like Firejail show it can be done without much friction for the user.
The current model, where executables can access any user file or resource, needs to go. We haven't learned anything from e.g. compromised pip packages that stole ssh keys.
> If iOS or Android added robust support for external monitors, external keyboards and pointing devices, I'd probably switch to it to get the increased resistance against attacks.
They basically do now?
On iOS I've never seen a BT keyboard not pair and I've never had problems with external monitors. Sometimes getting the right dongle so it plugs in is the bigger problem, but iPads have been USB-C for a while now, making it pretty much a non-issue, whenever I've tried.
I haven't tried with Android in a while, but I'd be surprised if it's much different than iOS at this point in time.
Can iPadOS display a UI tailored to the native resolution of the external monitor such that the user need never interact with the iPad's own display?
Is using a mouse with Mobile Safari a pleasant experience if the user is doing many hours of interaction that way?
(Actually, now that I think about it, iPadOS is too restrictive for me: I can't configure it in ways I would want to, but GrapheneOS doesn't have that problem what with being almost entirely open-source.)
> Can iPadOS display a UI tailored to the native resolution of the external monitor such that the user need never interact with the iPad's own display?
Well, since the iPad display is also the touchpad, you probably don't want to never interact with the iPad display. But essentially yes. Some TV's have a worse time than others. iPad's can't control what the TV can handle. In general, I've never had big problems, though I don't use it for 8hr work sessions.
> Is using a mouse with Mobile Safari a pleasant experience if the user is doing many hours of interaction that way?
Nobody can tell you if what they have implemented now, works well enough for you. I use it regularly, it works great.
> (Actually, now that I think about it, iPadOS is too restrictive for me: I can't configure it in ways I would want to, but GrapheneOS doesn't have that problem what with being almost entirely open-source.)
backing out already?! :) Seriously though, you are not alone. iPadOS is restrictive, that is either a bonus or a curse. It does let you focus more on tasks, but it limits how you are used to working in ways that might be hard to handle(especially at first).
I agree about GrapheneOS.
As for emacs, you can run it under iSH on iPadOS. I can't tell you how well it works, since I don't use emacs.
Thanks for the info, especially your "I use it regularly, it works great."
>iPadOS is restrictive, that is either a bonus or a curse. It does let you focus more on tasks
I used to compress my browser's executable as a way of "disabling" it. That stopped working smoothly after MacOS locked down the /Applications directory, but I found other ways to disable my browser: on Gnome now, I wrote a command that is easy to invoke and that removes browsers from "the Dash" (Gnome's analog to the Dock). (The command is implemented with `gsettings set org.gnome.shell favorite-apps`.)
Note that this method of "disabling" the browser does not prevent me from starting the browser with a command line entered into a terminal window, but it does stop me from starting the browser in a way that requires no thinking from me (i.e., the way I habitually do it) which turns out to be enough to prevent me from wasting time in the browser.
Being able to easily "disable" the browser (or more precisely, to easily arrange it so that I need to think in order to switch to a browser window) has significantly reduced the amount of time I waste online. Of course, there are times when some pressing task requires use of a web browser (which might coincide with one of the times when my ability to resist the temptation to waste time on the web is low) but in my life, those times are rare.
Yes, iPadOS offers a way to disable Safari, too, but the difference is that doing it on iPadOS requires many steps, and it hard for me to muster the self-discipline to go through the steps after I've noticed my ability to stay focused has gotten so low that I should disable my browser: the steps are this: go to Settings > Screen Time > content & privacy restrictions. Toggle on the button at the top of the pane. Enter a 4-digit passcode.
There is no way for me to customize my iPad to make it easier for me to disable Safari.
This relative lack of customizability is why I would hesitate to try to rely on iPadOS for productivity. (Currently my iPad is almost entirely an entertainment and distraction device. When I need to be productive and feel that my ability to resist the temptation to waste time on it is low, I can and do move my iPad to another room.)
Android does have support for external keyboards and I know mice work but not the totality of pointing devices. There was a desktop experience with Samsung's DeX, complete with floating windows, but the experience was severely broken due to lackluster app support and clashing design priorities between touch and mouse.
Thing is that Android is probably no more secure than a standard desktop experience specifically due to the very uncontained Play Store, the prevalence of sideloading apps and rooting doesn't really help at all.
> Thing is that Android is probably no more secure than a standard desktop experience specifically due to the very uncontained Play Store, the prevalence of sideloading apps and rooting doesn't really help at all.
This is completely untrue. There is lot more to OS security than where software can be downloaded from. The point about root and sideloading is completely missing the point as those are even worse on desktop operating systems. On desktops you can basically run whatever from wherever and there is usually no sandboxing at all. On Android, there is a strict sandbox and you can't run whatever you want. Android is not rooted by default.
Every app is strictly sandboxed on Android, point me to a desktop OS that has anything close to that. Every process is confined using SELinux policies on Android, which desktop OS has as strict MAC setup? Android has a proper, working verified boot, which desktop OS has something similar? Not to mention all the other hardening and exploit mitigations that are usually completely missing from standard desktop operating systems.
Responsible disclosure is immediate public disclosure with no embargoes. Embargoes are how we as users are absorbing the costs of poor security practices. If the culture was a no-warning publish culture, I would expect feature iteration and API breaks to slow down to more conservative levels as bikeshedding that stuff dwindles.
Punish fast software development iteration with public embarrassment and lost users who got hosed by the vulnerability. If Apple or whoever start dicking around and not paying bounties, release it... or better yet: sell it on the darknet; you have got to be paid for your good work, and NSA/NSO are going to need more 0-day vulnerabilities with WWIII underway!
I've found a number of bypasses myself, and I'm not even a security researcher, just a longtime app developer. I know where the bodies are buried, so to speak. However, I ultimately gave up looking, because Apple's security vulnerability reporting system is absolute trash; their only interest seems to be to keep you quiet for as long as possible. It's a waste of time.
My overall feeling is that macOS has become the victim of security theater, harming both users and legitimate developers with enfeedbled software and an endless stream of permissions requests—much like Apple's old parody of Windows Vista—while doing nothing to stop real attackers, who can easily bypass the security theater whenever they want.