m(DM)acOS

[ Disclaimer: This blog post is only a personal, ficticious thought experiment. If you’re a Mac administrator, I recommend you read it. Regardless of whether this thought experiment turns out to be reality or fiction, the conclusion contains some very good advice that I’d recommend - no matter what the future holds. - mike ]

Howdy.

It’s been almost a year or so since my last blog post.

I’ve been kinda busy with my fun new job.

I’ll try to do more fun posts soon-ish (did you see this neat thing I did at the PSU Macadmins hackathon called nibbler?)

But I wanted to take some time to write this out, since it’s been rattling in my head since WWDC: MDM is (probably) coming.

Maybe. I’m guessing. But I think all the clues are there.

If you didn’t pay much attention to the last WWDC Apple held, there was some amazing information about the things to come.

The best part is that it’s ok to talk about it, because they updated their Developer License agreement section “Information Deemed Apple Confidential” to include the following words:

Further, Apple agrees that You will not be bound by the foregoing confidentiality terms with regard to technical information about pre-release Apple Software and services disclosed by Apple at WWDC (Apple’s Worldwide Developers Conference), except that You may not post screen shots of, write public reviews of, or redistribute any pre-release Apple Software, Apple Services or hardware.

What I will be discussing here is a theoretical connect-the-dots with only two main components: Technical details that Apple has disclosed at WWDC and existing features in currently shipping Apple operating systems.

So what did Apple talk about at WWDC that was so amazing?

The Apple File System (APFS)


Apple had an entire session on it (which you can watch without a Developer ID).

At WWDC, they also made available technical documentation on APFS (again, available without a Developer ID, even shows up in Google results).

The biggest bombshell in both of those products are these lines from the technical documents:

Apple File System is a new, modern file system for iOS, macOS, tvOS, and watchOS. […]

Apple plans to release Apple File System as a bootable file system in 2017.

and these words from the video session:

[34:36] So to summarize, Apple File System will be the default file system for all Apple products [in] 2017, it’s ultra-modern, it’s crash protected, it supports Space Sharing, we support cloning and snapshots.

This is Apple talking at WWDC about the next family of operating systems to be released after Sierra. Apple is stating that the new default filesystem will be APFS across everything.

At this point you may be asking: How does that apply to MDM and why did you even make this blog post in the first place?

Almost there, just need to set the stage a tad bit more 😄

Let’s take one other statement from the video session:

[33:28] Instead, Apple will provide an in-place upgrade path from HFS+ to Apple File System.

For all the other devices besides Macs, they’re already running on a modified form of HFS+ with security features that you don’t see in macOS. APFS for these devices is basically a 2.0 filesystem of what they’re already doing, the next generation meant to replace and improve the existing situation. To me, this last quote feels like they’re saying: “While we’re upgrading everything, we’re going to be bringing the Macs in line with everything else.”

… So what do the OSes running on these filesystems on iOS/tvOS/watchOS look like right now?

  • You can’t use open source tools or third-party tools to install them
  • The OS is cryptographically signed
  • The OS is effectively separate from user content

Apple touts these as security features - and I agree 100% they are and I love them.

Apple has been on a direct path towards increased user privacy and OS security (see their BlackHat talk, watch for the “Physical One-Way Hash Function”) and I appreciate their efforts.

But they don’t have it on macOS.

So why wouldn’t they try to bring it over?

… I’m pretty sure they’re going to. Very very soon.

In fact, here’s Apple’s own words on it, from their session video:

[23:44] In addition, this allows us to unify our encryption story across all of our platforms.

Already, with Sierra, Apple has given a considerable number of indicators that their OS and OS update delivery mechanism is changing:

  • Sierra now downloads from the App Store even without being signed in
  • It no longer shows up in your Apple ID’s purchase history, even if signed in
  • It will automatically download to your machine if you have “download newly available updates” enabled
  • The Software Update Service is deprecated (see the bottom of this article)

Again I hear you asking: What does this all have to do with MDM?

Apple looks to be rapidly shifting how OS delivery works on macOS.

What if they’re changing OS installation to “unify our OS story”?

What would you do if the entire OS that is macOS - if all of it was protected, like it is on iOS/tvOS/watchOS?

I don’t just mean /System and the things that SIP protects now.

I mean everything that the “Install macOS Sierra.app” installs on your machine now.

We’re talking /etc, /var, portions of /Library, etc. in addition to everything SIP already protects in Sierra now.

Are you an administrator of Macs like I am?

What if you couldn’t change ntp.conf?

Or ssh_config?

Or mess with the default User Template? (I can’t stand it if you do this, but it is supported by Apple right now)

What if everything that is macOS was locked away?

How would you manage it?


Question: How does Apple offer the ability to do that now with iOS and tvOS?

Answer: Profiles!


Question: How do you get those on your iOS devices in an automated fashion?

Answer: MDM! (or Configurator, in some cases)


If APFS is the gateway that makes macOS immutable, the road to it is being paved in whatever OS comes after Sierra, where it will be landing as the default filesystem (if they keep to their goals).

That is extremely fast movement on Apple’s part:

  • Public testing of a brand new filesystem APFS in Sierra
  • APFS now default filesystem in Sierra+1, with conversion of existing HFS+ filesystems to APFS
  • … road paved for locked down OS delivery by Sierra+2 ? (Maybe +3 at the latest?)

And with the goal of a unified filesystem making the goal of a unified OS protection scheme within tantalizing reach - I wouldn’t be surprised to see Apple take from their existing playbook and attempt to unify their OS management model as well, offering profiles as “the solution” for everything OS management related on macOS.

What’s the impact of a change like this?

For the average computer user with .apps installed, web browsing, etc. they honestly might not notice a thing.

… But for a Mac administrator in a large organization?

What good is a root-running LaunchDaemon or client agent when everything that came with the OS is immutable?

What does root even mean anymore in that situation?

Are you running chef? puppet? munki? Casper?

Are your management tools performing security-oriented or legally-required customizations to your systems with custom scripts/logic you designed?

What if they couldn’t?

When all that’s left is userspace, will local administrators even need to exist? Do you have admin rights on your iOS devices right now?

This is part of why I tweeted, asking my fellow Mac administrator followers what they’re doing right now that they can’t do with a profile at the moment on macOS.

If everything you’re managing right now isn’t filed in a radar to Apple asking for an officially approved mechanism to manage this aspect of their OS, how will Apple know to give you a handle on wrangling these settings when they change the security model of macOS to “unify their OS story”?

I got a lot of responses. I’ll be writing them up and filing them as radars. I hope you do the same.

There’s more, though

For a Mac administrator, the impact of such a change as this would be much more than just settings management.

Do you “golden master” / block level restore your iOS devices with tools like AutoDMG, Imagr, DeployStudio, or Casper Imaging?

Or do you use Apple Configurator because that’s the only choice that’s available?

If Apple is going to “unify [their] encryption story” on macOS, do you think any of the tools you have now will be able to install this new style of OS deployment?

Do you NetBoot image iPhones and iPads?

I know, I know, I’m reallllly stretching the comparisons quite a bit here - the technological history of these families of devices were vastly different and resulted in different technology management chains and solutions …

… But Apple is in a unifying phase now, and the dates they promise seem like they’re accelerating it.

If they’re willing to kill off a very mature filesystem like HFS+, why wouldn’t they be willing to kill off NetBoot (FYI: introduced a year after HFS+)?

The story I paint here is quite possibly the death of most management and imaging workflows in enterprise existence today for macOS (or, at best, the ignition for the firey phoenix-like rebirth of the existing tools we have today).

For some, this will feel like a bleak story.

Or even a scary one.

In the name of security.

I personally think it’s a worthy goal.

But there will be a lot of blood, sweat, and toil for the administrators trying to get their environments compatible should this new future come to be.

And if this is the future, Apple really really really needs to engage more organizations directly and plainly about this future. We would need their help in making this a successful transition as much as Apple would need our help keeping our organizations from being so overwhelmed they’d consider moving to Linux or Windows to avoid the pain of such a major revamp.

We all have undocumented internal changes in the name of security.

Workarounds for bad bad bad experiences (automated GarageBand and Xcode installs with all the components, anyone? I mean come on, this isn’t even third-party software !!)

Script after script after script (reordering wifi networks? trying to get certs working with third-party VPN clients?)

… But if Apple doesn’t know about them and hasn’t heard about them from us, they might assume that they’ve provided us (the administrative community) with 95%+ of the tools that we need. Instead of the closer to 15-25% (or less) reality you feel you’re successfully “mitigating” with internal solutions.

And what about reliability?

What if Apple followed the model they have in iOS right now and the advanced “enterprise” management profiles required DEP / supervision?

There are lots of those settings on iOS. I wouldn’t be surprised to see more of them appear on macOS.

What if DEP was critical to the management settings you needed - and …

DEP

went

down?

It’s happened already.

Now spinning up new devices for your organization is stopped because DEP has an outage - and there’s literally nothing you can do but wait.

Literally no amount of money your organization can spend on engineers to reduce the time of this problem to an equivalent-to-zero value.

Is DEP as a purchasing and/or network service even available in all the markets where your organization currently purchases devices? Do you know?

Or how about APNS?

MDM uses APNS to push a trigger to clients to check in sooner for updated management instructions.

What if APNS fails? Your clients would still check in … eventually … sometime … maybe in 6 hours-ish? Is that fast enough? Is that level of configuration responsiveness compatible with your enterprise environment?

How about cost?

Right now I know of a grand total of 2 open source MDM projects that specifically target macOS. And they are brand new - the oldest is a year old. And being brand new, they are raw tools for people who know what they’re doing and to experiment on. You would be hard-pressed to enroll your organization of 500+ devices into them today and expect to be able to manage all the things you want (even if all the profiles you needed magically already existed).

This means you’re almost mandatorily looking at a pay-for MDM vendor solution when you may not currently have one (common when your organization relies on open source tools).

This is a cost your organization hasn’t currently budgeted for your Macs. And it’s also a product that any engineers you had working on your open source tools won’t necessarily be able to have as much of an instant impact on, as the MDM solution will be closed source and you’ll be restricted in what you can do by the product’s API.

Would your engineers even be able to work on open source MDM?

Apple has some of the MDM specs published but this isn’t all of the documentation they have. Some of the documentation is gated behind their MDM Vendor program, which is only available to Apple Enterprise customers. Additionally, an open source MDM would need an Apple signed MDM cert to function correctly, also available through members of the MDM Vendor program. Apple hasn’t made it easy for open source MDM to exist, let alone functionally run.

Are you a school? Do you even have engineers? Do you even have a budget for something like this? Or at all?

How likely is this?

Did you see that JAMF just renamed their MDM solution Bushel to “JAMF Now”?

… Does that make Casper “JAMF Then”?

Maybe ask someone at Apple.

What could one do to prepare?

  • Inventory your existing management settings
  • Attempt to find configuration profile solutions for all of them
  • If they don’t exist, file radars with Apple listing the following things:
    • Identify the setting and configuration options you need
    • Explain why the setting is important
    • Explain the impact of being unable to change this setting
    • Explain whether alternative methods exist currently to change it
    • Explicitly identify the number of impacted Macs / possible sales this could impact
  • If your organization has an Apple business contact, you should talk to them about the feasibility of managing your organization’s Macs with MDM
  • If you do business in countries other than the US, you should check with Apple on the availability of DEP-enrolled Mac purchasing and service globally

Don’t boo, radar.

- mike