Ever since the kids from Silicon Valley went to TechCrunch, I’ve been thinking that at some point I’d want to put a piece there. Luckily, I recently got the chance. Today, 16 Apple Security Advances To Take Note Of In 2016 went up on TechCrunch. You can access the article here.
The original article actually listed the year that each was introduced in order. It was a lot of work to go back in time and piece the timeline together, so since the years didn’t make it through editorial, I list them here (not that anyone actually cares):
And yes, since I was there for each of these, I did feel old writing this… :-/
And yes, thank you for asking, I did just publish another book on Mac Security, which you can buy here.
krypted January 18th, 2016
By default, OS X now updates apps that are distributed through the Mac App Store (MAS). OS X Server is really just the Server app, sitting on the App Store. If the Server app is upgraded automatically, you will potentially experience some adverse side effects, especially if the app is running on a Metadata Controller for Xsan, runs Open Directory, or a major release of the Server app ships. Therefore, in this article we’re going to disable this otherwise sweet feature of OS X.
To get started, first open the System Preferences. From there, click on the App Store System Preference pane.
From the App Store System Preference pane, uncheck the following boxes:
Once disabled, you’ll need to keep on top of updates in the App Store manually. My recommendation is still to create an image of your server before each update.
krypted October 2nd, 2015
The Caching Server in OS X Server 5 (for El Capitan and Yosemite) now does content and Software Updates. Woohoo, the promised land. Now, when 10 of your users download that latest Nicholas Sparks book and movie, you only sacrifice your WAN pipe to download it once, and the other 9 people piggy-back off that. And when OS X El Capitan ships, you only need to download it over the WAN once, and the other local users will pull off that spiffy Caching Server sitting in your office. Pretty sweet, right?
So, how do you use this ultra-complicated service. Well, it looks and feels kinda’ like an iPad app. Which is to say that as far as server stuffs go, this thing is pretty darn easy to use. To get started, open the Server app and then click on the Caching service in the sidebar of the Server app.
Here, click on the ON button. OMG, so hard. But wait, there’s more! Click on that Change Location button and you can select a larger volume for your updates that are cached. You’ll likely wanna’ do this because the entire series of OZ is kinda’ big (and yes, creepy, but really well written)…
If you do change the location, you’ll see a window to change the volume you’re caching to. That’s pretty much it. Other than the waiting for the updates to move. By default, the Caching service allows for unlimited space. Use the spiffy slider to reduce the total amount of space that the service can occupy on the hard drive. This can be a good thing if it happens to be your boot volume and there are other more mission critical services hosted on that thing.
Overall, this all seems pretty straight forward. So what else might you need to know. In case you get a corrupt asset, or in case your volume fills up, there’s a Reset button, to reset the cache.
The service can be controlled from the command line as well. To start it, use the serveradmin command along with the start verb and the service name (oddly, that’s caching).
sudo /Applications/Server.app/Contents/ServerRoot/usr/sbin/serveradmin start caching
To stop the service, use the stop verb along with the service name:
sudo /Applications/Server.app/Contents/ServerRoot/usr/sbin/serveradmin stop caching
To see a list of settings, use the settings verb with the service name:
sudo /Applications/Server.app/Contents/ServerRoot/usr/sbin/serveradmin settings caching
The settings are as follows, mostly available in the Server app:
caching:ReservedVolumeSpace = 25000000000
caching:CacheLimit = 350000000000
caching:ServerRoot = "/Library/Server"
caching:ServerGUID = "DEE63BBB-9F32-428B-B717-E3941F82E2DC"
caching:DataPath = "/Library/Server/Caching/Data"
caching:LocalSubnetsOnly = yes
caching:Port = 0
One setting you might choose to change is the reserved volume space, as this can keep you from getting the service started on smaller volumes. In the above example, the setting is 250 gigs. To change that to 100 gigs:
sudo /Applications/Server.app/Contents/ServerRoot/usr/sbin/serveradmin settings caching:ReservedVolumeSpace = 10000000000
krypted September 20th, 2015
I’ve seen a few instances where an upgrade caused Final Cut to run kinda’ strangely. To resolve, I’ve just been doing a quick reinstall of Final Cut. To do so:
Once done, go back to the Mac App Store and reinstall Final Cut and open it. Those folders you just tossed out will get re-created. Your toolbars and other customizations are likely to be gone, so you’ll have to spend a few minutes getting your workspace back to the way you had it, but if Final Cut was acting oddly it should be back to normal.
krypted January 21st, 2015
With Yosemite in beta, it’s worth mentioning that older versions of OS X Server are still available on the app store, if you just know where to look. You can access and purchase other versions using these links:
Server 1: If you already own OS X Lion Server from the app store then you can still access it under Purchases.
krypted June 1st, 2014
Posted In: Mac OS X Server
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):
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 = "public.app-category.video"
kMDItemCFBundleIdentifier = "com.apple.iMovieApp"
kMDItemContentCreationDate = 2011-09-28 08:04:34 +0000
kMDItemContentModificationDate = 2012-09-22 02:13:45 +0000
kMDItemContentType = "com.apple.application-bundle"
kMDItemDisplayName = "iMovie"
kMDItemExecutableArchitectures = (
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/iMovie.app -name kMDItemCFBundleIdentifier /Applications/iMovie.app
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:
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:
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/iMovie.app -name kMDItemVersion /Applications/iMovie.app
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:
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 com.apple.storeagent.plist 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/com.apple.storeagent.plist 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).
krypted November 19th, 2012
Users can log into the Mac App Store using their personal Apple ID. Users can also log into the Mac App Store with an AppleID that is linked to a company owned email address instead. The AppleID itself should be a company owned asset so that if/when users leave the organization, the organizations till owns the software that they purchase. Whether purchasing software through a volume purchasing program or directly, those dollars are wasted if the user is purchasing software through a personal AppleID. Therefore, you need a way to look at what AppleID that a user is using and to make sure that the organization has a way to link that account information back to the host the user is using and/or change the information if the user were to move to a different system.
In order to find the AppleID that a user is using, look into com.apple.storeagent. As the user, simply run defaults and read that domain along with the AppleID key:
defaults read com.apple.storeagent AppleID
When you run this, you see the Email address of that user. The DSPersonID is then listed here as well, as well as any other accounts (by DSPersonID) that have AppleIDs attached to the host. That DSPersonID is used throughout iCloud, actually. If you have installed iCloud through the system preference pane you will end up with Back to My Mac keys and other keychain assets that reference back to the keychains.
Now, to defaults write data into this domain isn’t as simple as you might think. The problem is that you would need to know the AppleID’s DSPersonID. You would also need to deploy the keychain items for the AppleID application password and the certificate for the AppleID, which has a com.apple.idms.appleid.prd.CN, or common name.
krypted November 11th, 2011