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. An app distributed outside the Mac App Store runs from a randomized path when it is launched and so cannot access such external resources. To provide secure execution, code sign your disk image itself using the codesign tool, or distribute your app through the Mac App Store. For more information, see the updated revision to macOS Code Signing In Depth.
This is further explained in the equally misnamed “OS X Code Signing In Depth“:
If using a disk image to ship an app, users should drag the app from the image to its desired installation location (usually /Applications) before launching it. This also applies to apps installed via ZIP or other archive formats or apps downloaded to the Downloads directory: ask the user to drag the app to /Applications and launch it from there.
This practice avoids an attack where a validly signed app launched from a disk image, ZIP archive, or ISO (CD/DVD) image can load malicious code or content from untrusted locations on the same image or archive. Starting with macOS Sierra, running a newly-downloaded app from a disk image, archive, or the Downloads directory will cause Gatekeeper to isolate that app at a unspecified read-only location in the filesystem. This will prevent the app from accessing code or content using relative paths.
The gist is, if an app isn’t signed via the Mac App Store, Gatekeeper is going to limit the ability of the app to launch via “Gatekeeper Path Randomization.” Basically, treat an app from a mounted drive as if it were coming from a Safari download. There are a few ways to distribute app bundles or binaries that do not violate this. One is to sign a disk image that contains such an app:
spctl -a -t open --context context:primary-signature -v /Volumes/MyApp/MyApp.dmg
If spctl runs properly, you should see the following:
/Volumes/MyApp/MyAppImage.dmg: accepted source=mydeveloperid
In the above spctl command, we use the following options:
- -a assesses the file you indicate (basically required for this operation)
- -t allows me to specify a type of execution to allow, in this case it’s ‘open’
- –context
- -v run verbosely so I can build error correction into any scripts
- –status while I don’t use status, I could do a second operation to validate that the first worked and use the status option to check it
- –remove I also don’t use remove, but I could undo what I just did by doing so (or just deleting the dmg
For more on managing Gatekeeper from the command line, see https://krypted.com//mac-security/manage-gatekeeper-from-the-command-line-in-mountain-lion/.
Another method is to remove the lsquarantine attribute, which is automagically applied, using xattr as follows:
xattr -r -d com.apple.quarantine /Volumes/MyApp/MyAppImage.app
The options in the above use of the xattr command:
- -r run recursively so we catch binaries inside the app bundle
- -d delete the com.apple.quarantine bit
Xattr has a lot of different uses; you can programmatically manage Finder tags with it, http://https://krypted.com//mac-os-x/command-line-finder-tags/. To see the full xattr dump on a given file, use the -l option as follows:
xattr -l com.apple.quarantine MyAppImage.dmg
The output is as follows:
xattr: No such file: com.apple.quarantine
MyAppImage.dmg: com.apple.metadata:kMDItemDownloadedDate:
00000000 62 70 6C 69 73 74 30 30 A1 01 33 41 BE 31 0B A5 |bplist00..3A.1..|
00000010 70 D4 56 08 0A 00 00 00 00 00 00 01 01 00 00 00 |p.V………….|
00000020 00 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 |…………….|
00000030 00 00 00 00 13 |…..|
00000035
MyAppImage.dmg: com.apple.metadata:kMDItemWhereFroms:
00000000 62 70 6C 69 73 74 30 30 A1 01 5F 10 22 63 69 64 |bplist00.._.”cid|
00000010 3A 69 6D 61 67 65 30 30 31 2E 70 6E 67 40 30 31 |:myappimage.dmg@01|
00000020 44 32 36 46 46 44 2E 35 37 31 30 37 30 46 30 08 |D26FFD.571070F0.|
00000030 0A 00 00 00 00 00 00 01 01 00 00 00 00 00 00 00 |…………….|
00000040 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |…………….|
00000050 2F |/|
00000051
This could be helpful when troubleshooting and/or scripting (or just way too much informations!).
Finally, if you’re an application developer, check out new API for App Translocation in the 10.12 SDK for <Security/SecTranslocate.h> I guess one way to think of this is… Apple doesn’t want you running software this way any more. And traditionally they lock things down further, not less, so probably best to find alternatives to running apps out of images, from a strategy standpoint.
