Wednesday, December 18, 2019 [Tweets] [Favorites]

Persistent File Access via com.apple.macl Xattr

Jeff Johnson (Hacker News):

I’ve discovered that on Catalina, pasting a file from Finder not only outputs the file path in Terminal, it also invisibly and permanently grants Terminal access to the file, bypassing any macOS privacy protections!

[…]

Notice that after copying from Finder, the Documents folder has a new com.apple.macl extended attribute. (I’ll assume the “l” in “macl” stands for “lockdown” until someone tells me otherwise.) This special extended attribute gives Terminal (and possibly other apps?) special access to the file. The com.apple.macl extended attribute, as well as the special file access, is persistent across reboots. Indeed, it remains even if you reset the privacy permissions of Terminal!

The com.apple.macl extended attribute is so persistent that you can’t even delete it.

Unless you turn off System Integrity Protection. This seems so much more convenient than the way it works for sandboxed apps, where the app is responsible for storing and using a security-scoped bookmark.

See also: Quinn the Eskimo.

Update (2019-12-19): Rosyna Keller:

Indeed, this was documented in the Advances in macOS Security session at WWDC. To prevent spurious dialogs when a file access is clearly due to a user action (like dragon drop/manual file opens, double-click in the finder) access is inferred by the user’s action and granted.

I watched that session and don’t think it really conveyed what is going on:

And user privacy protections in macOS Catalina now support the notion of user intent, when-- which is inferred when double clicking on files in Finder, when dragging and dropping from another application or when selecting files in an Open or Save panel.

And when the user performs any of these actions, the file-- performing any of these actions on a file protected location, your app gets access to the file or files that the user selected without the need for a consent prompt. So let’s see how Catalina’s inference of user intent compares with user consent. Sorry. So, first of all, user consent is reactive. Access may be granted only after your app tries to read or write a file, whereas user intent is proactive. Access is granted before the app, even tries to read or write the file. And user consent prompts to kind of interrupt the user’s workflow, whereas user intent is inferred from standard UI interactions. In order to minimize those interruptions, user consent applies to an entire class of data, for example, all files on your desktop.

Whereas user intent is inferred for just the file or files that the user is interacting with.

Jeff Johnson:

As developers, we need to test our software under known conditions. That’s when all these inscrutable irrevocable privacy protection exceptions become a nightmare. tccutil reset was good enough on Mojave, but now it’s not on Catalina. Apple offers no good solution to the problem.

Update (2019-12-20): Howard Oakley:

The com.apple.macl xattr contains a list of UUIDs for the apps which can open it, each with a prefix 0100 containing a single flag which presumably grants that file-specific entitlement. There can be one or several UUIDs, which are stored there in binary, not text[…]

[…]

There are some worrying features in Catalina, though. I have written before about the promiscuous use of the quarantine flag on documents in Mojave and earlier. I regret to report that this behaviour doesn’t appear to have changed at all, and in many current Catalina installations the new com.apple.macl xattr will be outnumbered by all those devalued quarantine flags. This also gives rise to some strange consequences: open a PDF in Preview without saving it, and it will be given a quarantine flag but no com.apple.macl xattr. If you try to Save that to overwrite the original document, Preview promptly refuses, and may not even be able to write that file out under another name. Repeat that with a PNG file, and Preview has no such problems.

Previously:

Jeff Johnson:

At least with the quarantine xattr, the value contains the bundle id of the app that wrote it. The macl is effectively untraceable.

Update (2019-12-26): Jeff Johnson:

I received a link to a video from the PSU Mac Admins conference in August that mentioned the macl xattr I blogged about recently.

Not much new info on that subject, but relatedly, the speaker said the quarantine xattr may apply to curl in the future!

3 Comments

How to delete this attribute from a file?

[…] these are good questions, but there’s no official documentation. A good start is this assemblage of articles, here’s the highlights from that page and a few […]

I encountered the same problem where Preview disallowed saving edits to a PDF because of this flag, and can confirm that the below workaround allows you to do so when you encounter this issue.

https://discussions.apple.com/thread/250850461

Stay up-to-date by subscribing to the Comments RSS Feed for this post.

Leave a Comment