Tiny Deathstars of Foulness

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 Another method is to remove the lsquarantine attribute, which is automagically applied, using xattr as follows: xattr -r -d /Volumes/MyApp/ The options in the above use of the xattr command:
  • -r run recursively so we catch binaries inside the app bundle
  • -d delete the bit
Xattr has a lot of different uses; you can programmatically manage Finder tags with it, To see the full xattr dump on a given file, use the -l option as follows: xattr -l MyAppImage.dmg The output is as follows:
xattr: No such file: MyAppImage.dmg: 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: 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.

January 25th, 2017

Posted In: Mac OS X, Mac Security

Tags: , , , , ,

As you may have noticed, we’ve been working on building some links between the App Store and patch management tools such as Casper, FileWave and Munki. We’ve been looking at policy-based management of apps as well. In this semi-new world of signing and stores and the such, there’s actually a good bit you can ascertain about an app both inside the app as well as inside metadata OS X keeps about the app. I’ve discussed signing (apps and packages) in the past, but let’s look at using some commands to help us out with some tasks. The first command is to determine some information about apps that are on the computer. Spotlight keeps a fair amount of information about these apps and can be invoked using the mdls command. Running the command with no additional parameters looks like this (I’m gonna’ use iMovie in these examples, although note that there are spaces in a lot of app names and paths as you start scripting things – so use IFS rather than trying to use traditional array): mdls /Applications/ This results in output similar to the following (I’ve stripped out a few fields as they consume a lot of space and aren’t super pertinent to what I’m trying to do here):
kMDItemAlternateNames = ( "" ) kMDItemAppStoreCategory = "Video" kMDItemAppStoreCategoryType = "" kMDItemCFBundleIdentifier = "" kMDItemContentCreationDate = 2011-09-28 08:04:34 +0000 kMDItemContentModificationDate = 2012-09-22 02:13:45 +0000 kMDItemContentType = "" kMDItemDisplayName = "iMovie" kMDItemExecutableArchitectures = ( i386 ) kMDItemFSContentChangeDate = 2012-09-22 02:13:45 +0000 kMDItemFSCreationDate = 2011-09-28 08:04:34 +0000 kMDItemVersion = "9.0.8"
To just ask for one of these attributes, run the command along with the -name option in addition to the metadata attribute you’d like returned. For example, to see the bundle ID (kMDItemCFBundleIdentifier), use: mdls /Applications/ -name kMDItemCFBundleIdentifier /Applications/ Now, if you’d like to just quickly ascertain what apps on the system came from the App Store, use the mdfind command, along with whatever of the attributes matches what you want to know. Running mdfind for kMDItemAppStoreHasReceipt of 1 would look like the following and would result in a list of all apps on the system that came from the App Store: mdfind kMDItemAppStoreHasReceipt=1 Blacklisting all apps that are part of a specific category (and with regard to customer requests, that category seems to always be Games) is something we get a lot of banter about with customers. To determine this information for apps, you can run mdfind on kMDItemAppStoreCategory for Games: mdfind kMDItemAppStoreCategory=Games You could then dump the contents of those into something that can blacklist apps (or whitelist based on other categories). Now, version control is another hot topic at various organizations. To see the version type of a given app, use the -name option with mdls kMDItemVersion mdls /Applications/ -name kMDItemVersion /Applications/ Then you can track the version of the app and take action through other ways to remove old versions and force users to upgrade. The mdfind command can also be leveraged to find apps that have escaped their traditional homes of /Applications and /Applications/Utilities, with the ability to obtain a full list by querying for kMDItemContentType of app bundles, as follows: mdfind kMDItemContentType="" Loading a list of apps (output from `mdfind kMDItemAppStoreHasReceipt=1` or `mdfind kMDItemAppStoreCategory=Games`) into an array and then querying each one of them for more information is pretty trivial beyond the steps we’ve already taken. This information can then be fed into some kind of Managed Prefs script to deny or allow access to various objects or an admin could even chmod the bundle, mark it as invisible, poison it (keep in mind, if you alter it you’ll break the signing), etc in order to get some desired outcome. You can also use defaults to read a users file for the AppleID field to see what AppleID is currently logged into the AppStore, providing another variable that can be reported on: defaults read /Users/cedge/Library/Preferences/ AppleID And yes, it’s worth noting that users from another account or a system image, etc can be used to download apps so this one isn’t exactly certain but the purchaser isn’t stored anywhere within the bundle nor is it permissioned in a way that we can use to find the purchaser that way. There’s still a bit of a gap right now with regards to some of these technologies that Mac SysAdmins are managing. The consumeristic technologies such as App Stores are here to stay. We’re kidding ourselves if we think that we won’t be able to buy certain apps via Volume Licenses and have pkg installers for too much longer. Apple has made no indication that they’re dropping the results that can be obtained with a simple installer command, but with forcing signing on certain objects, gatekeeper and other technologies it’s hard to say what the future will really have in store for us. Getting to a point where we can report on elements of the App Store and hopefully eventually deploy objects through the App Store should continue to help bridge these factors, but I still see the need for additional binaries from Apple to be introduced to get the rest of the way there (or at least expose a method to me so I can go in there and buy an app through the method).

November 19th, 2012

Posted In: Mac OS X, Mac OS X Server, Mac Security, Mass Deployment, Uncategorized

Tags: , , , , , , , , , , , , , , , ,