As promised, here’s the slide deck from my talk at MacAD.UK in London. Enjoy!
krypted February 7th, 2017
When you’re regression testing, you frequently just don’t want any delays for scripts unless you intentionally sleep your scripts. By default Safari has an internal delay that I’d totally forgotten about. So if your GUI scripts (yes, I know, yuck) are taking too long to run, check this out and see if it helps:
defaults write com.apple.Safari WebKitInitialTimedLayoutDelay 0
With a script I was recently working on, this made the thing take about an hour less. Might help for your stuffs, might not.
If not, to undo:
defaults delete com.apple.Safari WebKitInitialTimedLayoutDelay
krypted February 1st, 2017
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:
For more on managing Gatekeeper from the command line, see http://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:
Xattr has a lot of different uses; you can programmatically manage Finder tags with it, http://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
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 |…..|
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 |/|
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.
krypted January 25th, 2017
Built a quick extension attribute for Jamf Pro environments to check if TouchID is enabled and report back a string in $result – this could easily be modified and so I commented a few pointers for environments that might need to modify it (e.g. to check for user-level as it’s currently system-level). To see/have the code, check https://github.com/krypted/TouchID_check.
krypted January 18th, 2017
OS X Server stores most logs in files that are in the /Library/Logs/ProfileManager directory. Logs are split up between php, devicemgrd.log, scep_helper.log, servermgr_devicemgr.log, profilemanager.log and others. In my experience, if there’s a lot of errors at first, or if the service doesn’t work, just reformat and start over. But, once a server is in production, you don’t want to re-enroll devices after you do that. So, as with all good error prodding, start with the logs to troubleshoot.
By default the logs can appear a bit anemic. You can enable more information by increasing the logging level. Here, we’ll shoot it up to 6, which can be done with the following command:
sudo debugDeviceMgr 6
Debug levels go all the way to 9, but at that point things get… Noisy. And to turn it back off, use:
sudo debugDeviceMgr 1
Basically, this command sets the required services in /Applications/Server.app/Contents/ServerRoot/System/Library/LaunchDaemons/ to debug mode as well as /Applications/Server.app/Contents/ServerRoot/usr/share/devicemgr/config/com.apple.DeviceManagement.postgres-debug.plist and /Applications/Server.app/Contents/ServerRoot/usr/share/devicemgr/config/com.apple.DeviceManagement.postgres.plist to configure debug mode. In other words, it touches a lot of services. And given how chatty some can be, only leave logging levels higher than I’d say 2 in the event of short-term troubleshooting.
krypted December 29th, 2016
krypted December 28th, 2016
Apple recently introduced a laptop with the same fingerprint technology found in an iPhone as well as a T-1 chip to take the sapphire Touch ID sensor information and store it securely, non-reversibly(ish), on the machine. OS X 10.12 now comes with a tool that can manage the fingerprints, stored as keys, on the device. The bioutil command is simple to use, with a few options that are mostly useful for enabling different features of the new technology.
Let’s get started by enabling the unlock option, using the -r option to see if Touch ID is enabled for the current user and -s to check the system as well:
bioutil -r -s
Now let’s enable Touch ID to be able to unlock the system, with -u (provided it’s not already enabled):
If you’ll be using ApplePay, also use -a (on a per-user basis):
Next, let’s enables Touch ID to unlock the system for the current user:
bioutil -w -u 1
This user will obviously need to provide their fingerprint in order to use Touch ID. Once done, let’s see how many fingerprints they’ve registered using the -c option (which checks for the number of fingerprints registered by the currently enrolled user):
Now let’s delete all fingerprints for the current user (note that they’re not reversible so you can’t actually look at the contents):
Next, we’ll use sudo to remove all fingerprints for all users (since we’re crossing from user land, we’ll need to provide a password):
sudo bioutil -p -s
Instead, we could have targeted just deleting the fingerprints that had been registered for user 1024, using -s and -d together, followed by the actual UID (which also requires sudo – as with all -s option combos):
sudo bioutil -s -d 1024
Now let’s disable Touch ID for the computer, using -w to write a config, and that -u from earlier, setting it to 0 for off:
sudo bioutil -w -s -u 0
And viola, you’re managing the thing. Throw these in an Extension Attribute or in Munki and you’re managing/checking/knowing/reporting/all the thingsings! Enjoy!
krypted December 16th, 2016
The last JamfNation User Conference, or JNUC for short, was far and away the biggest and best. It was packed though, and given the year-over-year increase in people attending, the conference is being moved to the Hyatt Regency in downtown Minneapolis.
For more information on or to early-bird register for JNUC 2017, visit the official JNUC page.
I’ll certainly be there, and I look forward to seeing all of you again and meeting all the newcomers this year, as well as getting a recording going of the MacAdmins Podcast while we’re all together!
krypted December 11th, 2016
macOS has keychains. Sometimes they’re a thing. When they are you might want to delete them. Let’s say you have an admin account. You want to keep the keychains for that account, but remove all the others. For this, you could do a shell operator to extglob. Or you could do a quick while loop as follows:
ls /Users | grep -v "admin" | while read USERNAME do; rm -Rf "/Users/$USERNAME/Library/Keychains/*" done;
If you borrow this, be careful.
krypted December 1st, 2016