With Apple’s new System Integrity Protection (SIP) in OS X 10.11, the Mac is now ever more secure. But with SIP comes some additional restrictions that affect how System Administrators can make Windows bootable during deployments.
SIP prevents any user (including the all powerful root user) from writing to specific locations in OS X (mainly in the System Folder). Rich Trouton has some great info on SIP at his Der Flounder blog here that cover the folders that are protected and some great information on NetBoot and SIP.
One of the protections that SIP puts into place is a restriction from modifying the startup disk programatically:
Configuring System Integrity Protection (developer.apple.com)
Note: To safeguard against disabling System Integrity Protection by modifying security configuration from another OS, the startup disk can no longer be set programmatically, such as by invoking the bless(8) command.
You can still set the Startup Disk using the Option key at startup, or by using the Startup Disk System Preference Pane. However, you can no longer change NVRAM or the boot sector on the disk. NVRAM holds the currently selected disk for next reboot.
In prior versions of OS X, you would use the “bless” command to change the bootable disk. This now fails, as “bless” writes to NVRAM, which is protected by SIP (even for the root user). Bless is still on the system for a couple of reasons. First, if SIP is disabled, the prior functionality returns. Second, Apple utilities (such as the Startup Disk preference pane) use bless to set the selected startup disk. But how is Apple able to use “bless” and restrict its use for anyone else? OS X uses digital signatures to determine if bless can be run. Only Apple apps signed with a identity from Apple and a correct entitlement are allowed to run the bless command.
This all relates to Boot Camp and booting Windows through the boot sector. The boot sector is the first sector on a hard disk, and is usually used when legacy booting Windows. SIP restricts access to the device that OS X is booted from (usually /dev/disk0), even for the root user.
This is where the situation gets interesting. Modern Macs always boot via EFI, but Windows hardware has only recently started natively booting EFI. While there was some support for EFI booting Windows 7, Apple didn’t support EFI booting Windows until Windows 8. With the newest Apple hardware, Windows 8 or later is required, and EFI booting is the only way that Windows will boot on the Mac.
Usually you don’t have to worry about any of this, since Boot Camp Assistant and the Windows installer will set everything up correctly. But what happens if you are mass deploying Boot Camp and having issues?
If you use Disk Utility to create a Boot Camp partition on El Capitan (10.11) or earlier, OS X will create what is called a “hybrid master boot record (MBR)”. This lets Windows boot via “legacy” mode, which (as mentioned before) is not supported on the newest Macs. You can see it in OS X using the fdisk command:
SIP does not prevent you from reading information (such as the Master Boot Record), but does prevent any writing to the MBR.
If you use Boot Camp Assistant to create the Boot Camp partition, you’ll get a standard EFI “guard” MBR:
The hybrid MBR has an entry for each of the first 4 partitions. The guard MBR has only a single entry that covers the entire disk (used to protect legacy tools from doing bad things).
The difference is important, since it affects how Windows will boot. If Windows 7 or earlier is running on older Macs, it needs to have a hybrid MBR. If Windows 8 or later is running new Macs, a standard “guard” MBR is required. If the wrong type is used, Windows will refuse to boot (usually with a black or blue screen). The common way to resolve this issue was to write a new MBR, but since SIP restricts access to the master boot record, it seems impossible unless you disable SIP.
However, there are a couple of workarounds. Since Apple tools can write a MBR, you can use this to get the MBR in the correct mode. Here are the tools and what they do:
Disk Utility (or diskutility command line):
- If a FAT or XFAT partition is created in partition 4, a hybrid MBR is created.
- If a HFS+ partition is created in partition 4, a guard MBR is created.
- If partition 4 is erased (rather than deleted and then created), the MBR will not change.
- If a partition is deleted and partition 4 becomes a Windows partition, a hybrid MBR is written.
Boot Camp Assistant
- New Macs (support only Windows 8 and later): A guard MBR is written.
- Older Macs (supporting Windows 7): A hybrid MBR is written.
Using these tools, you can create the MBR in the state that you want. If you are on a newer Mac, and want a guard MBR, you have 2 options:
1. Use Disk Utility, and create a small (10 MB or so ) HFS+ partition at partition 4 and the Windows partition at partition 5. You can also use the disk utility command line:
This takes a standard OS X partitioned disk and shrinks the OS X partition to 400 GB, create a 10 MB HFS+ partition, and fills in the rest of the space with a MS-DOS partition.
This results in a guard master boot record. You can’t delete the HFS+ partition after Windows is installed since that results in a hybrid MBR being written.
2. Use Boot Camp Assistant. Boot Camp assistant will create a disk layout that looks like this:
You can see from the above screen shot that the BOOTCAMP partition is created on slice 5, right after the OSXRESERVED partition used to install Windows. After the next reboot into OS X, OS X will automatically delete the OSXRESERVED partition and put the space back into Core Storage. When this partition is deleted, the MBR is not converted from guard to hybrid. The MBR will remain a guard MBR, which is exactly what you want for EFT-booting Windows such as Windows 8 or later.
Apple is making great strides in securing OS X, and SIP goes a long way to protect the system. With some knowledge and understanding, you can still get the same or similar behaviors from prior versions of OS X, and with the extra protections of SIP.
Find this article interesting? Let me know what you think by tweeting at me on Twitter: @tperfitt