Mac sandbox escape

Completely agree and you put this perfectly.

The problem is not the viewing, but editing. When you say "Open In Photoshop" does this mean you can make changes and then save the "file"? What if Photoshop doesn't just "save" a file, but writes several intermediate files onto the filesystem and does a bunch of file renames to create a "backup" of the original image. Those operations are no longer just operating on a single file any more. From the perspective of a security system implementor, how can you understand such intent from sequences of raw POSIX filesystem calls -- because that is all the sandbox enforcement code in the OS kernel gets to see and approve or deny.

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.

> I get the apps want to present their own UI for the photos.

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.

I thought that was already how the macOS sandbox worked?

The issue is with apps that aren't sandboxed (basically anything outside the app store - e.g. Adobe apps)

https://developer.apple.com/library/archive/documentation/Se...

> 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

Maybe explaining to the user the implications of controlling TextEdit? How scope is expanding? Just thinking out loud here.

My takeaway is more that the entire security model that Apple is pushing for the Mac just doesn't really make sense. E.g., here's a quick list of apps that aren't sandboxed: Logic Pro, Final Cut, most of Adobe Creative Cloud, Visual Studio Code/Atom/TextMate, Xcode, and Sketch. If I were to make a list of the main apps people buy Macs to run, it's pretty much the same list.

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.

Judging by the entitlements, it seems that a script can save an executable file. Would it be possible to ensure that any file written by a script remains quarantined?

> I'm curious what the author things a good resolution for this would be.

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 class of problem is interesting and well-known because it doesn't have a great resolution within the most popular access control schemes.

https://en.wikipedia.org/wiki/Confused_deputy_problem

Tricking a higher-privileged bit of code into doing the bidding of a lower-privileged app is really common in the history of nasty security exploits. Windows Kernel developers and Web Browser developers have both spent over a decade systematically eliminating scenarios where this can happen, whether it's forging WM_TIMER messages or attempting to get around javascript API origin/trust restrictions.

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

And to explain his argument he explained

> 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!

I believe there’s a feature that allows others to take control of the screen. It could be related to this

I would imagine it’s used for scheduling meetings in other apps.

iirc remote mouse & keyboard control was added recently.

You have the problem that too much information will just get skipped over by the user too. It has to be the right length of text if you want to try and get them to read it.

There is a bit of confusion because macOS has two sandboxes: app store app isolation and permissions and file system isolation. Think of the latter as everything on the file system except /Users and a few other cherry picked directories being mounted from a read-only CD-ROM.

I work on the platform all day, and I would not put that together as obviously dangerous.

The author is right that controlling TextEdit seems harmless. It could be done in the context of showing the user release notes or something. AppleEvents must be a nightmare for Apple's security auditors.