At Apple’s recent event, the release date for the next release of OS X (El Capitan) was “leaked” in the above shown email.
Not only is this release going to be the most magical since the last one, it’s main focus seems to be on performance & security. The latter of which will affect us admins, especially System Integrity Protection (read: SIP).
This post will try to explain one way SIP may affect you, & possibly how to prepare.
Contents
System Integrity Protection
Apple has some documentation on SIP here, the key concepts of which can be found below:
- System Locations Cannot Be Written To
- System Processes Cannot Be Attached To
- Kernel Extensions Must Be Signed
- System Integrity Protection Is Configured On Recovery OS
Rich Trouton has a great post on the first key concept, & that can be found here, it’s the last concept that I’m going to go into more detail in this post.
NetBooting and System Integrity Protection
As Rich Trouton (again) has blogged & noted, Apple have taken the unusual & welcome step of releasing a KB article on the changes in 10.11 in the KB (despite some confusion on the KB): Prepare for NetBoot, NetInstall, and NetRestore requirements in OS X El Capitan.
Rich has an awesome image to depict whether or not this will affect you:
Chicken & Egg
So, if you need to NetBoot your clients via the bless command how &/or when can you add a trusted NetBoot server to the Macs whitelist & where is this record kept?
How?
The below command can be run when booted from a 10.11 Recovery Partition & when booted into a 10.11 NetInstall & NetRestore, (a 10.11 NetBoot may well work too, but i’ve not tested yet).
csrutil netboot add <address>
To get a list of the whitelisted address enter:
csrutil netboot list
The issue comes in that if you need to use bless to NetBoot a Mac, then you’ll need to first boot the Mac into the Recovery Partition & then add the netboot servers to the whitelist.
Where?
The whitelist is then written to the booted Macs NVRAM, which is Non-Volatile until you reset it.
That’s not a particularly uncommon troubleshooting technique, & will then undo the hard work you put into whitelisting your NetBoot servers.
Less Faff More NetBooting
So rather than faffing around with csrutil, what other options are there? Well, there are two alternatives:
- Move your NetBoot Servers onto the same VLAN as your NetBooting clients
- Add IP Helpers.
The 1st option is probably the most drastic & could possibly be logistically unfeasible, & the latter is the one that seemingly makes network admins panic.
IP Helpers
IP Helper addresses are used within environments for things such as DHCP, NetBoot & PXE.
The fact that the IP Helpers are used for DHCP is what seems to make network admins get all twitchy.
However, IP Helpers can be put in place for both DHCP & NetBoot. The below is somewhat the process involving those when NetBooting a Mac:
- The NetBooting Mac makes both a DHCP & BSDP Discover (BSDP stands for Boot Service Discovery Protocol).
- The DHCP server responds with the clients DHCP Discover with an IP address (the Offer).
- The Mac responds to DHCP server the Offer with a Request to be allocated the address Offered.
- The DHCP server then Acknowledges the Request.
- The NetBoot server responds to the BSDP Discover, Informing the client of the available images.
- The Mac Acknowledges the Information from the NetBoot server &
- The Mac then Selects a NetBoot image to boot from.
The above is “kind of” right, it’s been cobbled together mostly from this Mike Bombich article. But the important take aways are:
- NetBoot is not DHCP.
- DHCP & NetBoot can be run the on same network, they will both be sent the Discover requests but will only answer the requests for the service they are offering (DHCP will only answer to DHCP, NetBoot will only answer to NetBoot).
If you Network Admins prefer more diagrams, Parallels also have this KB.
Less Faff, More NetBooting
With the IP Helpers in place, Mac clients will send their BSDP Discover requests via to the addresses defined in the IP Helpers without needing any whitelisting.
So, if resetting NVRAM is a thing you do regularly & you currently need to use the bless command to NetBoot.. IP Helpers can greatly simplify the process.
Also, as if you’re using either AutoCasperNBI or AutoImagrNBI neither of those will help a 10.11 client NetBoot to a server requiring whitelisting in the 1st instance. The solution? IP Helpers.
Since you can’t add it via NetBoot (AutoCasperNBI) image, this is looking to be a complete disaster for us. If you can’t add it without a NetInstall or NetRestore image (per Apple), which we don’t use and which don’t deploy Casper-based imaging, or without manually using the Restore partition (which is impractical), there appears to be no way forward.
Simply saying “use IP Helpers” is not helpful. Machines have firmware passwords, System Preferences has locks. In most enterprises, the user doesn’t have the ability to use the “browsing” methods of startup disk changing. Indeed, the only reason/time to do it is for support reasons, which should be done via a Apple Remote Desktop, Casper Remote, and such — which ultimately use the bless command.
Once we upgrade machines to OS X 10.11, we’re utterly rooted. The machine will not be able to be refreshed or re-imaged without someone going on-site, which is a MAJOR step backwards from what we currently accomplish remotely.
The only thing I can think of, which makes me just want to completely vomit, is to host both our normal AutoCasperNBI NetBoot imaging environment AND a special 10.11 NetInstall/NetRestore that has been hacked to buggery, to:
* add a LaunchDaemon as the machine starts up to run a script.
* the script csrutil whitelists the “real” NetBoot addresses, blesses the “real” NetBoot address(es) and then immediately initiates a restart to take it to the “real” imaging environment.
I can’t believe they’ve taken such unnecessary measures for so little benefit, without thinking things through properly and with such drastic repercussions.
Wait, it’s Apple. Yes, I can believe it.
From Apple:
This issue behaves as intended based on the following:
csrutil must be run from the Recovery environment to successfully use the ‘netboot add’ command. It won’t work from a normal NetBoot client.
More specifically, it has to run from a BaseSystem-based image. If it’s a regular image trimmed down to look like it, it’s not going to work.
So, you either have to image with their crippled, limited system, or run around with your Option-key pressing finger.
Right, this post was to advise on Apple’s stance & ways to mitigate.
There’s not much I can do.
Option-Key will not work if IPHelpers not in place though, & if you add netboot servers via csrutil then zap NVRAM.. they list is cleared.