Privacy and Security in macOS 14
Even though the photos look like they are part of your app, they are rendered by the system and only shared when selected, so the user’s photos always remain in their control.
[…]
Prior to macOS Sonoma, when a user wants to screen share their presentation in a virtual video conference, they need to grant the conferencing app permission to record the full screen via the Settings app, resulting in a poor experience and risk of oversharing.
With the new SCContentSharingPicker API, macOS Sonoma shows a window picker on your behalf where people can pick the screen content that they want to share.
[…]
Second, if you prefer to provide your own UI for creating events, there is a new add-only calendar permission, allowing your app to add events without access to other events on the calendar.
[…]
Without any changes on your side, macOS Sonoma will ask for permission when your app accesses a file in another app’s data container.
[…]
To do so, you can specify an NSDataAccessSecurityPolicy in your app’s Info.plist, to replace the default same-team policy with an explicit AllowList.
In macOS 14 and later, the operating system uses your app’s code signature to associate it with its sandbox container. If your app tries to access the sandbox container owned by another app, the system asks the person using your app whether to grant access. If the person denies access and your app is already running, then it can’t read or write the files in the other app’s sandbox container. If the person denies access while your app is launching and trying to enter the other app’s sandbox container, your app fails to launch.
The operating system also tracks the association between an app’s code signing identity and its sandbox container for helper tools, including launch agents. If a person denies permission for a launch agent to enter its sandbox container and the app fails to start,
launchdstarts the launch agent again and the operating system re-requests access.
I didn’t see this [alert] the first time I ran the app, but I saw it every time I modified and re-ran the app. The reason, I discovered eventually—by remembering what I read yesterday (the above quotes)—is that the app was both sandboxed and ad hoc code signed. Ad hoc code signing is indicated by “Sign to Run Locally” in Xcode.
You’ll frequently see ad hoc signing in open source Xcode projects that are distributed on the internet, because otherwise the project would depend on the developer’s personal team and code signing certificates.
[…]
Every time I modified the app, it got a different ad hoc code signature, which is why Sonoma is complaining on subsequent launches. These cancel-or-allow style dialogs do not appear on launch for ad hoc signed apps that aren’t sandboxed, because they don’t have containers.
[…]
I said, “I don’t know yet whether there’s a way for a non-sandboxed app to preserve the granted file access across launches.” The answer appears to be no.
Previously:
- Xcode 15 Announced
- macOS 14 Sonoma Announced
- Apple Abandons CSAM Scanning
- Advanced Data Protection for iCloud
Update (2023-06-19): Howard Oakley:
Until Apple tells us otherwise, I think it’s clear that nothing is changing significantly in sandboxing and notarization that would prevent hobbyists and others who aren’t developers from continuing what they do currently, nor should this hinder the distribution and use of source code.
Update (2023-06-23): macOS 14 Beta 2 Release Notes:
/usr/bin/syspolicy_checkis a new command line tool to help determine if the provided macOS application will pass the current running configurations’ system policy. This includes the same checks performed by the Apple notary service and other macOS Trusted Execution layers such as codesign, Gatekeeper, XProtect, and more.[…]
/usr/bin/gktoolis a new command line tool to assess Gatekeeper Policy on applications.gktoolcan be called to pre-warm the system cache so users do not see the ‘Verifying…’ dialog on first launch of an application.
spctl is still there, too.
Update (2023-06-29): Brian Webster:
- The top message in the prompt doesn’t tell the user which app’s data is being read. In this case, my NSAppDataUsageDescription string explains what PowerPhotos is reading, but there’s no actual relation between that message and what files are actually being read. In other words, a malicious app can easily lie to the user here.
- Unlike most of macOS’ security prompts, this one is displayed every single time the user launches your app, regardless of whether they’ve granted permission in the past. Not only is this just annoying, but this will quickly train the user to dismiss these prompts without reading them, which undercuts the whole purpose of the feature in the first place.
I’ve filed a Feedback (FB12473837) with Apple that basically suggests that these prompts should work more along the line of the existing “Automation” prompts, which are triggered when one app sends an Apple event to another app.
Update (2023-07-26): I am getting reports that sometimes Sonoma doesn’t prompt for App Management access. It just fails the operation with a permissions error.
3 Comments RSS · Twitter · Mastodon
Remember when Apple would make fun of Vista for having Cancel or Allow prompts? Now Apple’s software is a bigger joke, because Vista made sense back then. With Apple, none of this makes sense.
[…] are obviously plenty of frustrations and problems with Apple’s sandboxing model in MacOS. Yet there are also many cases where sensitive data is stored in plain text. The […]
