NetBooting and System Integrity Protection
Apple took an unusual step this week and released a knowledgebase (KBase) article that refers to an as-yet unreleased operating system:
Prepare for NetBoot, NetInstall, and NetRestore requirements in OS X El Capitan
I can only praise the decision to create it. The content covered affects a number of enterprise Mac environments and gives the Mac admins who support those environments time to prepare for an important change which may affect them.
That said, the KBase article itself is confusingly written and also includes an error. For more details, see below the jump.
In El Capitan, System Integrity Protection (SIP) affects the bless command’s ability to set alternate boot disks, including the ability to designate a NetBoot set as a startup drive.
To help folks who need to use bless to set a NetBoot set as a startup drive, Apple is providing functionality in the csrutil tool referenced in the KBase article to add NetBoot servers to a whitelist.
This whitelist will define by IP address which NetBoot servers are trusted in your environment. Once those IP addresses are part of the whitelist, the bless command can set a Mac to NetBoot from a NetBoot set on a trusted NetBoot server.
To hopefully help clarify the issue, please see the graphic below.
Meanwhile, there also appears to be an error in the KBase article. The section with the error is below:
The last sentence includes this part:
“…using the bless command-line tool.” That is incorrect, as bless is not able to tell the Mac to trust the NetBoot server.
The correct way to tell the Mac to trust the NetBoot server is to use the new csrutil tool:
“…using the csrutil command-line tool.”
With that change, the section should now read as follows:
Add a trusted NetBoot server
The System Integrity Protection feature of OS X El Capitan requires that you tell your Mac to trust the NetBoot server. You can do that by using the Bless NetBoot Server action in the System Image Utility app, or by using the csrutil command-line tool.
To help get this issue corrected, I’ve filed a bug report on this KBase article. For those interested in duping it, it’s bug ID 22575339.
For those interested in the details, I’ve also posted the bug report to Open Radar:
Leave a comment
Recent Comments
 | Ben LeRoy on Losing a giant |
 | Peter-Erik on Downloading installer packages… |
 | nathanhaggard on Losing a giant |
 | andras0602 on Disabling login window clock d… |
 | Jeff on Losing a giant |
Der Flounder 
Are you sure this only applies to the bless command? After all, the Startup Disk prefpane, the Set Startup Disk option in Apple Remote Desktop, etc. all use the same infrastructure as the bless command to write the NetBoot settings to NVRAM.
So I suspect your graphic should say “Do you hold down the N or Option key to NetBoot? Yes = no SIP whitelisting required, No = SIP whitelisting required.” Of course, I haven’t actually verified that, but from a technical perspective, that’s the only thing that would make sense.
Apple addressed this at the beginning of the KBase article:
Select a network disk image
With OS X El Capitan, you can continue to use any of these methods to select a NetBoot, NetInstall, or NetRestore disk image from which to start up a Mac:
Use Startup Disk preferences: Choose Apple menu > System Preferences, then click Startup Disk.
Use Startup Manager: Hold down the Option key while starting up.
Hold down the N key while starting up to use the default image on the NetBoot server.
This is worthless. What enterprises don’t have firmware passwords, or lock users out of Startup Disk? Being THAT concerned about rogue NetBoot servers but not performing the most basic of security hardening (to protect business data) is quite simply incompetence.
Ok, then I don’t get what Apple is trying to achieve here. If you can’t use bless, you could probably script the GUI of the Startup Disk prefpane to achieve the same result, so no security gained there. Anyway, an attacker who is able to execute bless might not be able to do a NetBoot, but he could e.g. create and bless a local partition with a different OS install (e.g. Linux or pre-ElCap OSX) and work from there.
What they are trying to stop is people sudo/root escalation issuing a bless command to boot the machine remotely to an unauthorized netboot server that would not show up in the gui. ie over the internet or in some isolated/hidden network.
We use bless via script to automate our labs to boot as needed to the netboot server to apply updates. The script checks nightly for updates to that machine and if need netboot. We will have to get our netboot server into the whitelist.
This is a serious disaster. Most enterprises are not using Apple’s NetRestore/NetInstall images – they’re using Casper or other similar systems – and the Recovery partition is impractical because it requires manual intervention. Since NetBoot (e.g.: AutoCasperNBI) is specifically excluded from supporting csrutil whitelisting, enterprises are generally f***ed because all their automations and workflows are now dead in the water for an extremely esoteric condition (seriously, if someone can get root access to the machine, then your enterprise data is already compromised – who cares about a disposable, replaceable machine?).
We have Self Service-initiated upgrades. Gone.
Casper Remote-initated re-imaging. Gone.
Apple Remote Desktop-initated re-imaging of an entire lab on another campus. Gone.
What am i getting in return? Protection from something that has never happened to us in a decade of NetBoot-based imaging.
This is a really bad move from Apple, just to mention this is not working well… trying to deploy an image over the network now is almost impossible, even when I disable csrutil there is still problems.