Xip archives work back to Mac OS X 10.6. Xcode 8.0 betas are shipped as xip. Anon says: June 29th, 2016 at 9:59 pm @Rosyna I am pretty certain xip files have no effect on gatekeeper randomization / app translocation. I don’t think this is a mistake on Apple’s part either. App Translocation Services In OS X 10.12 The “ What’s New in macOS ” page for Sierra (10.12) lays out a little known change that a colleague at Jamf was working on the other day (hat tip to Brock): Starting in macOS 10.12, you can no longer provide external code or data alongside your code-signed app in a zip archive or unsigned disk image. May 21, 2018 Sierra added a new security feature officially named Gatekeeper Path Randomization, though it's also become known as App Translocation from the (non-random) name of the file path under which apps are run. The feature was carried over to High Sierra.
The safest place to get apps for your Mac is the App Store. Apple reviews each app in the App Store before it’s accepted and signs it to ensure that it hasn’t been tampered with or altered. If there’s ever a problem with an app, Apple can quickly remove it from the store.
If you download and install apps from the internet or directly from a developer, macOS continues to protect your Mac. When you install Mac apps, plug-ins, and installer packages from outside the App Store, macOS checks the Developer ID signature to verify that the software is from an identified developer and that it has not been altered. By default, macOS Catalina also requires software to be notarized, so you can be confident that the software you run on your Mac doesn't contain known malware. Before opening downloaded software for the first time, macOS requests your approval to make sure you aren’t misled into running software you didn’t expect.
Running software that hasn’t been signed and notarized may expose your computer and personal information to malware that can harm your Mac or compromise your privacy. View the app security settings on your MacMacos Sierra Gatekeeper App Translocation Download
By default, the security and privacy preferences of your Mac are set to allow apps from the App Store and identified developers. For additional security, you can chose to allow only apps from the App Store.
In System Preferences, click Security & Privacy, then click General. Click the lock and enter your password to make changes. Select App Store under the header “Allow apps downloaded from.”
Open a developer-signed or notarized app
If your Mac is set to allow apps from the App Store and identified developers, the first time that you launch a new app, your Mac asks if you’re sure you want to open it.
An app that has been notarized by Apple indicates that Apple checked it for malicious software and none was detected:
Prior to macOS Catalina, opening an app that hasn't been notarized shows a yellow warning icon and asks if you're sure you want to open it:
If you see a warning message and can’t install an app
If you have set your Mac to allow apps only from the App Store and you try to install an app from elsewhere, your Mac will say that the app can't be opened because it was not downloaded from the App Store.*
If your Mac is set to allow apps from the App Store and identified developers, and you try to install an app that isn’t signed by an identified developer or—in macOS Catalina—notarized by Apple, you also see a warning that the app cannot be opened.
If you see this warning, it means that the app was not notarized, and Apple could not scan the app for known malicious software.
You may want to look for an updated version of the app in the App Store or look for an alternative app.
If macOS detects a malicious app
If macOS detects that an app has malicious content, it will notify you when you try to open it and ask you to move it to the Trash.
How to open an app that hasn’t been notarized or is from an unidentified developer
Running software that hasn’t been signed and notarized may expose your computer and personal information to malware that can harm your Mac or compromise your privacy. If you’re certain that an app you want to install is from a trustworthy source and hasn’t been tampered with, you can temporarily override your Mac security settings to open it.
In macOS Catalina and macOS Mojave, when an app fails to install because it hasn’t been notarized or is from an unidentified developer, it will appear in System Preferences > Security & Privacy, under the General tab. Click Open Anyway to confirm your intent to open or install the app.
The warning prompt reappears, and you can click Open.*
The app is now saved as an exception to your security settings, and you can open it in the future by double-clicking it, just as you can any authorized app.
*If you're prompted to open Finder: control-click the app in Finder, choose Open from the menu, and then click Open in the dialog that appears. Enter your admin name and password to open the app.
Opening an app has become significantly more complex in macOS Mojave than it was in High Sierra, Sierra, or El Capitan. Each major release of macOS has brought substantial changes to the process: app translocation, more Gatekeeper and XProtect checks, and in Mojave the controls enforced by its privacy manager, TCC.
This article draws comparison between what is written to the log when you open a regular developer-signed app in Sierra and Mojave, and how a new ‘notarized’ app works too. In each case, I added a quarantine extended attribute to the app before opening it, to simulate what happens when the app has been freshly downloaded from the internet. This drives macOS to perform its fullest assessment of the app before it allows it to run.
In each of these log summaries, the clock time is given in blue at the start of the entry, following which the subsystem is shown in red. The remainder of the entry, shown in black, is the eventMessage. These are inevitably select highlights from thousands of entries over the time periods shown.
In macOS 10.12 Sierra, opening an app works the way that you probably think it should. The initial log entry, sendAction:, is part of the double-click to open the app. The app is then translocated into a specially-created folder to be run from there, as it is running for the first time with a quarantine xattr.
Then follows a Gatekeeper check, and assessment by XProtect. As the app has a valid developer signature and doesn’t match any of XProtect’s criteria for supposing that it is malware, its launch is allowed to proceed. This takes it on to the dialog in which the user is asked to confirm that they want to open the app.
The initial checking steps here take less than 0.5 seconds from first click to accepting the app as wholesome.
A regular signed app launched in macOS 10.14 Mojave appears quite different, although some of this is due to changed practices and policies for writing to the log. Once again, an early action is to translocate the app to a special folder, where XProtect performs its security assessment before running a malware scan on it. This initial security assessment takes just over 0.5 seconds, during which its signature is checked. As this is a first run in quarantine, this should include a deep check of the signature against blacklists.
When those are complete, LaunchServices is allowed to proceed with launching the app, but TCC, concerned with privacy protection, then runs its own assessment. Significantly, this includes checking which version of the SDK it was built against, which determines whether TCC’s strict new policies are applicable. In this case, the SDK version is 10.14 (hex 0a0d00), so this app will only be allowed to access protected data and services for which it has usage information strings in its Info.plist. As it isn’t hardened or notarized, it doesn’t have entitlements.
What I haven’t included here is the succession of errors when trying to check whether this app is notarized. In this case, it is because it is not, just signed in the ordinary way with a Developer ID.
Total time from first click to LaunchServices being allowed to proceed is here around 3 seconds, although this Mac is much faster than that running Sierra.
![]()
This is my app xattred, which is built against the 10.14 SDK, hardened and notarized, and has entitlements and usage information strings to support access to most protected data classes. It too is translocated to and run from a special folder.
Note that the XProtect security assessment here takes over 4 seconds, which includes time spent checking it not just against local databases, but verifying its notarization. LaunchServices then relocates its bundle and execution paths after a further delay of over 2 seconds, during which additional checks are made.
When TCC starts work on it, it still referred to it in its translocation folder, and is run from there. TCC knows that its runtime has been hardened, and applies the prompting policy appropriate to that, rather than just a Developer ID. This requires matching the entitlements which have been baked into its signature with the usage strings in its Info.plist. To be able to access any protected data, it requires both the appropriate entitlement and a usage string for that class of data.
Macos Sierra Gatekeeper App Translocation 2
The final entry given there (and for the previous app) is fascinating, but inexplicable without further knowledge of how TCC works. It refers to deriving a “team id” for the app for that given user ID. Presumably the outputs from these steps in TCC are stored in its database, ready for use when the app tries to access protected data or services.
Total time from first click to LaunchServices proceeding is now around 7 seconds, on the same Mac used for the previous Mojave test.
It is also worth bearing in mind that apps are normally only run once with their quarantine xattrs set. Subsequent launches undergo much briefer signature checks of integrity alone.
Macos Sierra Gatekeeper App Translocation Test
Updated 1640 3 October 2018 following helpful information from @lapcatsoftware pointing out that, although LaunchServices may relocate the bundle and exec paths during this initial run of an app in quarantine, the app is still actually run from translocation. On more thorough search of the logs from a non-notarized app, they behave just the same in Mojave, so this is not peculiar to apps which have been notarized.
Comments are closed.
|
AuthorWrite something about yourself. No need to be fancy, just an overview. Archives
December 2020
Categories |