Gatekeeper Change in macOS 15.4
On macOS 15.2, I was able to drag the exact same downloaded WebP file to TextEdit and BBEdit with no Gatekeeper alert! Thus, it appears that the Reddit poster was correct, and something did change recently.
[…]
I perused the unusually long Apple support document About the security content of macOS Sequoia 15.4, but nothing in there jumped out at me as the probable cause of the Gatekeeper change.
[…]
The appearance or nonappearance of Gatekeeper alerts depends entirely on the downloaded file’s extension. I edited the WebP file with a hex editor to make it into a plain text file, but it still triggered a Gatekeeper alert on opening in an app. On the other hand, when I kept the file contents the same, in WebP format, but changed the file extension to
.txt, the Gatekeeper alert no longer appeared.Overall, this feels like more security theater in macOS.
[…]
My test app will open any and every file type without a Gatekeeper alert, as far as I’ve seen, when the
CFBundleDocumentTypeshas a single entry declaring the genericpublic.datain itsLSItemContentTypes. The Gatekeeper alerts begin when I add a second entry with certain types, such ascom.apple.webarchiveorpublic.unix-executable. With just two declarations, one “safe” type such aspublic.dataand one apparently “dangerous” type such ascom.apple.webarchive, I see Gatekeeper alerts when trying to open any file, with any extension:.webp,.png, or even.txt.
He thinks the change in behavior may be a bug.
The problem (which has been around since macOS 10.0) is that it considers any file without a recognized extension to be an executable instead of being conservative and considering it something less. I always thought that to be a bad assumption. You cannot launch such executables directly from Finder anyway, so what’s the use case for this?
Yesterday, I saw a variation on this dialog that was new to me. I was trying to open a compiled nib file with Archaeology, and it said:
Apple could not verify “[file].nib” is free of malware that may harm your Mac or compromise your privacy.
The only two buttons were Done and Move to Trash. This is a document file, not executable code, and the only way I could open it was to delete the com.apple.quarantine xattr.
Previously:
- Archaeology 1.3
- macOS 15.4
- Gatekeeper vs. .terminal and .fileloc Files
- Sequoia’s spctl and csrutil
- Sequoia Removes Gatekeeper Contextual Menu Override
- Quarantine: Apps and Documents
- Sandboxing Makes Quarantine Flags Almost Meaningless
2 Comments RSS · Twitter · Mastodon
I'm not sure how or if it relates to the problem Jeff describes, but macOS has long been quarantine happy when a sandboxed app opens any writable file, even if the app declares its intention to only "view" it and never write it.
Basically, AppKit's state restoration machinery (for NSDocument) insists on creating a security-scoped bookmark for the document URL, and if that URL is writable to the app (e.g. NSURLIsWritableKey), AppKit makes a read/write bookmark (i.e. without using NSURLBookmarkCreationSecurityScopeAllowOnlyReadAccess). Within CoreFoundation, this triggers an open() call with O_RDWR to occur in the app process (to make a file descriptor that gets sent over XPC to ScopedBookmarkAgent), and the very act of opening the file read/write triggers the kernel (the Sandbox.kext?) to add the quarantine. I first observed this back in Monterey.
That's all orthogonal to why Gatekeeper thinks that even a quarantined nib file is dangerous, of course!
By the way, if you're working in the Terminal anyway, the Archaeology CLI tool (trowel) will allow you to open a file in a way that circumvents the Gatekeeper problem. That is, "trowel file.nib" won't trigger the Gatekeeper dialog even if the nib file is inexplicably quarantined. That's because this mechanism uses a URL handler rather than LaunchServices or an 'odoc' event. (It doesn't stop the quarantine from getting added when it's not already there, it only avoids getting Gatekeeper involved.)
"Overall, this feels like more security theater in macOS."
Jeff Johnson hits the nail on the head right there. macOS/MacOS X has been an utter security-un-architected mess since day one. It was obvious as soon as Apple decided to use .tle as a primary file type descriptor vs spending the time to develop a proper metadata replacement for resource fork data, IMHO. Everything appears to have been a 'bolt-on' since… and it shows. Apple—under Jobs—made so many architectural mistakes with Mac OS X that Windows offered ample examples of "why not?" that it makes me angry; and the stupidity continued into iOS. We're now left with primary operating systems that are terrible UX, poorly architected, with an Apple in no hurry to do better because they're richer than the pharaohs. Great. : /
