My text editor for example, I personally wouldn't mind if once per project I had to give it permission to access a project's folder.
I also wish there was a way to edit a file without giving access to the folder. For example Photoshop, I can select from the finder "Open In Photoshop" which is enough intent to give the app permission to access that file without having to give it access to the other files in the same folder.
I get that would require API changes and that Apple doing that overnight would break apps but basically going forward I wish OS makers would work toward something like that.
Even on iPhone I hate that apps either get permission to read all photos or none. Yes I get you can send a photo to an app but many apps can not receive them for every use. I get the apps want to present their own UI for the photos. Maybe some kind of OS run sandboxed process where the app can provide a limited function to present thumbnails but can't actually read any data and all they get out of that process from the OS is the user selected files? Oh well, I can dream.
If it were up to me and my 100k photo library, none of those apps would pass App Store validation because they are inevitably a miserable experience. Even the OS photo picker isn't 100% jank-free on that number of photos but it at least works effectively unlike everyone who implements their own (takes 30s to appear, photos in random* order, albums in random* order, smart* albums missing, extraneous albums, etc.)
> I hate that apps either get permission to read all photos or none
I thought they had introduced a "get a single photo for this app without photos permission" picker (I'm pretty sure I've used it in apps!) but I can't find any indication I'm not wildly hallucinating. But that would be a great thing.
It exists (https://developer.apple.com/documentation/uikit/uiimagepicke...) but apps don’t want to use it.
For code that uses Apple's Cocoa frameworks, when you ask at a high level to work on a file (or a bundle) a "Powerbox" is used -- it runs out of process and hands back the App permission to make modifications to that file (or bundle) based on the way Cocoa manipulates objects. If the app doesn't use Cocoa, the best that can be done is delegate permission to a directory.
The iPhone allowed a different security model to be created as there was no direct access to "files" and "folders". There were and still are problematic APIs that are based on a give me full access or nothing model. It is quite a challenge to retrofit a security model onto something that ultimately doesn't break something major in an unexpected way.
After the outcry to remove direct file access on Android 10, they decided to give one more version for devs to adapt to it, but it is coming on Android 11 no matter what.
And the old style access on Android 11 are just wrappers on top of SAF, which makes it even slower than using SAF directly.
On Windows, while UWP sandbox on its own might not have won lots of friends, with MSIX sandbox model for UWP/Win32 and the upcoming picosandboxes in Windows 10X also for UWP/Win32, these direct file APIs might eventually be a thing of the past, even if it still takes a couple of years to get there.
Ah and Linux applications on ChromeOS only sees what the hypervisor/gVisor allow them to see.
Or there is a way to bypass that and have access to the underlying FS?
(or am i entirely missing what you refer to?)
Powerbox actually has support for this.
Observing the system calls apps make can be eye-opening and sometimes very sad.
The issue is with apps that aren't sandboxed (basically anything outside the app store - e.g. Adobe apps)
> When a user of your app specifies they want to use a file or a folder, the system adds the associated path to your app’s sandbox. Say, for example, a user drags the ~/Documents folder onto your app’s Dock tile (or onto your app’s Finder icon, or into an open window of your app), thereby indicating they want to use that folder. In response, the system makes the ~/Documents folder, its contents, and its subfolders available to your app.
> If a user instead opens a specific file, or saves to a new file, the system makes the specified file, and that file alone, available to your app.
Starting in Catalina, even unsandboxed apps have gotten locked down a bit - you get permissions dialogs if they try to access Documents, Downloads or Desktop.
The exploit in the OP is using an open, world-writable directory (/Users/Shared) since it can't access user files
Perhaps that any time you use a text editor to create, edit, or save a shell script, that script should be treated as a freshly downloaded and untrusted script? Or that it should be impossible to control a text editor from another application, even when given explicit permission from the operator? Both of those sound awful. Is there a third option I'm missing here?
I'm with Apple on this one.
Also, who would think controlling a text editor is innocuous? A text editor's modus operandi is literally to create, read, update, or delete any file to which your user has access.
Files created by an app (app1) that is being controlled by another app (app2) should inherit the security context of app2, not app1 (or better yet, where privileges differ, apply the lesser of the the two). The fix should be applied where the security characteristics of a file are written. Perhaps that would mean introducing a new primitive that tracks when an app is being controlled by another app -- not sure.
Also, perhaps have special exceptions for files written to places like /Library/Application Support/app1/ -- an app's own working files are unlikely to present privilege escalation opportunities unless app2 is able to exploit a vulnerability in app1.
> Also, who would think controlling a text editor is innocuous?
I can think of several family members who might think "um why?" but not have any idea of the security implications.
This is definitely the case. When presented with a dialog that prevents progression, many, many users will click whatever makes it "go away."
However, when I see something like this, I get the heebie-jeebies. Apple's done a great job at locking down stuff, and when I have to provide accessibility or some other weirdness I know what I'm doing.
I think if a successful exploit of this started spreading, Apple might add some exception for TextEdit. But in lieu of that, I can only imagine the amount of substantial, unprompted security problems are quite extensive.
The particular case highlighted in the blog post is specific to code editors, but similar types of problems arise in all of the most important app categories for Macs.
Attempts to retrofit a sandbox to older OSs are full of holes, and it's interesting to see how different ecosystems attempt to do this, with containers, AppArmor, the seatbelt sandbox, and other things brewing in Redmond.
Personally I think it will be incredibly hard and tedious to morph the Linux desktop into a properly sandboxed environment, exactly because you are fighting long established conventions and norms in just about every aspect of development and application usage.
Fuchsia (Googles new OS) might prove very interesting in this regard.
Contrary to popular belief, you do not have to run every application in its own (VM).
You can run any number of apps in a single VM, so the principle is that you define what applications (use cases) can and should be isolated from each other and use multiple VMs to implement that segmentation between (groups of) apps.
For example, you can have one VM for all your work apps and another for the remaining use cases.
This is a path that started when people voted against UWP, then they went the other way around, bringing the UWP sandbox model to Win32.
First there was Desktop Bridge where Win32 apps would run sandboxed, but with full trust. Then came the MSIX package format that would apply a bit more of sandboxing and less trust than Desktop Bridge introduced.
Now with Windows 10X they are building on top of the picoprocesses that came from Project Drawbridge and were used in WSL 1 to wrap each Win32 application into its own little world.
It is only a matter of time until this expands to other SKUs.
As for the legacy applications, I guess just like with those stuck in Windows XP, either adopt the future or stay behind.
I have a very strong feeling that it will be Windows 10X that will be "left behind". The entire point of using Windows nowadays is to be able to use existing Windows applications.
Every time there were any issues, it was dealt with one step back two forward tactic.
In general i'm very confident i can make any older program or game for Windows to run on modern Windows 10 - usually with minor tweaks.
If Microsoft breaks this, i'm certain they'll completely misunderstand why people keep using Windows.
That is exactly the point. The apps you listed are used in tons of corporate environments and fairly well vetted, usually with bug bounty programs or full time security teams backing them. It's the smaller one-off apps that people aren't putting eyes on regularly that get sandboxed.
That's exactly what happened with Pixelmator, and it's happening now with the Affinity Suite. Before the sandbox, Pixelmator looked like it would one day be a real Photoshop competitor, but now they're mainly for people who don't want to pay for Adobe's subscription.
And, the real Adobe competitors are more likely to come from somewhere else, like the web with Figma. The funny thing is that now Figma is usable on an iPad, because it's a web app, and Sketch, which is an all-Apple technology AppKit app, isn't. Because web apps can avoid the sandbox, even on iOS. Some of the biggest beneficiaries of Apple's security strategy are poised to be some of the apps least invested in Apple's platforms.
Can you point to any evidence that the macOS sandbox is what’s holding Pixelmator back from dethroning the undisputed 20+ year king of professional photo editing?
Also, Photoshop was once also the undisputed king of user-interface design, but they were dethroned by Sketch, an app that was first released one year before sandboxing came into effect.
Is any of this conclusive? No. But do I see a pattern sandboxing putting a ceiling on how successful a creative app can be? Overwhelmingly yes.
And I seriously doubt that applications like Photoshop will migrate to them just because of that.
Nowadays this doesn't happen much because there is no incentive.
Also as i already wrote above, currently there isn't really much of an incentive for people to switch (outside of ideological and/or very niche reasons) so the "Desktop Linux dream" doesn't apply.
I am, at best, a journeyman in the ways of graphic editing and someone who bought Pixelmator the instant it arrived but this isn't right - it might have become a real Photoshop competitor for people who needed basic graphic editing facilities once or twice a month, yes. Same with Affinity Photo. Without a laser focus on quality-of-life tweaks and jank removal (haven't seen it in either yet!), they're both doomed to GIMP-level "coulda beena contender!" existence.
(Not sure why I'm being downvoted above)
(I can't explain the downvotes, either. Hacker News is fickle ¯\_(ツ)_/¯)
"I convinced this other program to dump an executable shell script onto disk for me so I could run it without a prompt" is a textbook escalation of privilege vulnerability, and being able to do it with a common app like TextEdit or BBEdit is pretty serious.
One solution is for the outermost caller's credentials to apply all the way down the chain. This is common in Windows and in web browsers - web browsers basically track whether the current chain of actions originated from user input or not so that they can prevent websites from silently doing nasty stuff without user consent. At this point browsers actually track that consent data across asynchronous computation so everything will work.
I personally don't think an app with 'create shell script' permissions should be able to be controlled by Joe's Random Unprivileged App, but that's just me. Windows certainly doesn't allow low integrity apps to communicate with arbitrary high integrity apps. Introducing that restriction is an essential security improvement.
> Then click to allow when the system dialog asks if the sample app can control TextEdit via Apple Events.
The author argues,
> This should appear very innocuous to the user, because nobody thinks that TextEdit is dangerous, so one would think it's not much of a risk to allow TextEdit to be controlled.
This is what the dialog looks like: https://imgur.com/a/HRXDG0x
The smaller text is where the app developer provides an explanation for why they are requesting the permission.
> However, when an app such as TextEdit with the "com.apple.security.files.user-selected.executable" entitlement saves a file, it removes the quarantine extended attribute!
[>] codesign -d --entitlements :- /Applications/zoom.us.app
What apple could do is perhaps add some sort of indication or extra step to help users make the informed choice.
> Note that I chose the directory /Users/Shared to avoid macOS "privacy protections" that prevent interaction with various other directories such as Desktop, Documents, and Downloads.
If the script can't access protected locations did it actually break the sandbox? Can you actually run the file in /Users/Shared scripts afterward and access those locations from there on? On Catalina the shell is kinda sandboxed when run interactively, does this exploit bypass by tuning as TextEdit?
Seems to require the user to explicitly give the application permission to escape the sandbox?
Even if TextEdit files were quarantined so you could not execute them, you would still be able to do harm, such as snooping on the user's recent documents, or trashing the disk by overwriting files that TextEdit has access to. Likely it could even install a LaunchAgent to run arbitrary code outside of the sandbox as well.
There's already a security dialog here that warns the user. Maybe the user's imagination doesn't run wild with all the ways that the access could be abused, but they _were_ warned.
I mean this isn't the first vulnerabilities of it's kind.
The author points to the sand, and Apple says "we're only interested in the castle."
In one sense, to agree with most of the comments here, thats the practical answer for Apple! Show us the problem with what we've built!
In another sense, I scooped the sand away from the foundation of your castle, and now I'm inside.