Contribute
Register

Explaining OS X El Capitan Security Changes - Workarounds and Current Information

tonymacx86

Administrator
Staff member
Joined
Nov 17, 2009
Messages
7,369
Motherboard
Z370N WIFI
CPU
i7 8700K
Graphics
HD 630
Mac
  1. MacBook Air
Classic Mac
  1. Apple
  2. PowerBook
Mobile Phone
  1. iOS
apple_lock_face.jpg
Over the past few OS X releases, Apple has tightened system security. They have gradually begun to bring OS X in line with iOS in terms of locking down certain areas of the system to the user.

In OS X El Capitan Apple has implemented ‘rootless’ security or System Integrity Protection (SIP). This locks down system folders and files against hacks and root attacks, thus keeping the system safer. As good as this is for security, it has made things much harder for the hackintosh community, requiring workarounds for established methods of installation and maintenance for generic PCs. It has become necessary to make drastic changes in order to modify current tools to inject unsigned kexts and alter system kexts. These changes are in testing and yet to be completed for the legacy bootloaders Chameleon/Chimera and the EFI bootloader Clover.

Starting with OS X 10.10 Yosemite, in order to load unsigned kexts the user had to pass the boot flag kext-dev-mode=1. As of OS X 10.11 El Capitan, that option is not available anymore.

Early OS X 10.11 El Capitan betas contained a new boot flag to disable rootless security called rootless=0. This has been removed in recent beta builds, and replaced with NVRAM csr-active-config. This provides much finer grained control over SIP, allowing the user to toggle the new rootless security options on and off either completely or partially. OS X also contains a new application on the Recovery Partition to enable or disable SIP.

A good rule of thumb is when rebuilding kernel cache on a hackintosh, SIP must be disabled. SIP must be disabled in order to install anything to protected system folders. SIP can also be disabled partially, to allow unsigned kexts in cache and install to protected folders.

We will likely eventually recommend that SIP be disabled from the beginning of the installation through post-installation process. After everything is set, and the user is successfully booting, SIP can be re-enabled.

As of today, the only bootloader that will inject kexts into protected cache and adjust SIP settings on the fly is Clover v3259 or later. Clover can set csr-active-config with config.plist/RtVariables/CsrActiveConfig and config.plist/RtVariables/BooterConfig=0x28.

Relevant user options for SIP are as follows:
csr-active-config 0x0 = SIP Enabled (Default)
csr-active-config 0x3 = SIP Partially Disabled (Loads unsigned kexts)
csr-active-config 0x67 = SIP Disabled completely

Clover config.plist:
Code:
    <key>RtVariables</key>
    <dict>
        <key>CsrActiveConfig</key>
        <string>0x3</string>
        <key>BooterConfig</key>
        <string>0x28</string>
    </dict>

As far as system protection goes, this is all new. OS X hasn’t had this level of system security before, and at this point it seems as if users can simply take it or leave it at their own risk. As Rehabman wisely said, “The sky will not fall if you disable SIP… it is equivalent to the security scenario we’ve been using on hacks for a long time.”

We expect that by the official launch of OS X El Capitan, bootloaders will be fixed and methods will be solidified. Guides and complete solutions should be available even for the most novice of users. For now, we've updated our El Capitan Public Beta USB installation guide with config.plist examples that will work with the latest Public Betas.

http://www.tonymacx86.com/el-capita...ublic-beta-installation-usb-using-clover.html

Special Thanks to toleda and RehabMan for their contributions to this report. Credit to Piker Alpha for his amazing in depth explanations on his blog.

Sources:
Official WWDC Video
https://developer.apple.com/videos/wwdc/2015/?id=706
https://pikeralpha.wordpress.com/2015/07/28/apples-kext-signing-bypassed/
http://sourceforge.net/projects/cloverefiboot/
 
Explaining OS X El Capitan Security Changes [DRAFT]

Workarounds:
In the simplest of terms, if you have SIP enabled and caches are rebuilt problems can occur. If SIP remains disabled via Clover's config.plist there should be no issues.

However if SIP is enabled, workarounds may be needed for most post-installation user processes where the kext cache is rebuilt. Workarounds for injecting kexts into the protected kernel cache include booting into Single User mode and passing commands to the system via the command line.

Installing any system update will trigger a cache rebuild. In order to boot successfully after updating, the user must be running with SIP disabled prior to starting the update. This requires enabling SIP via Clover's config.plist and rebooting. Updating a system with SIP enabled will result in an unbootable system due to the lack of the essential FakeSMC.kext in the cache.

To do a system update on OS X El Capitan:
1. Disable SIP
2. Apply System Update (with reboot)
3. Enable SIP, reboot

To fix an unbootable system, or to boot a freshly updated system, one must disable SIP, then boot into Single User Mode in order to rebuild the cache. This is done in Clover by pressing spacebar to access boot menu, then selecting "Boot Mac OS X in single user verbose mode". Type the following commands in order once the command line appears in verbose mode.

To fix an unbootable system via Terminal:
1. fsck -fy
2. mount -uw /
3. touch /System/Library/Extensions && kextcache -u /
4. reboot

Often, the EFI partition is not available to disable SIP.
1. At BIOS, boot with OS X El Capitan Public Beta Installation USB Using Clover_v3259 or newer (SIP is disabled with Post #1 attached config.plists)
2. On restart, boot with OS X El Capitan Public Beta Installation USB Using Clover_v3259 or newer
3. Rebuild kernel cache in Terminal: touch /System/Library/Extensions && kextcache -u /
4. Remove USB
5. Restart and boot normally
 
So does this mean it could be the end of the line for legacy bootloaders such as chimera and chameleon?
 
So does this mean it could be the end of the line for legacy bootloaders such as chimera and chameleon?

Good question- there is active development right now in the Enoch branch of Chameleon, and it can boot El Capitan successfully... however with the latest security changes, Clover may be the cleanest way to go forward. We're still exploring/testing as much as we can utilizing everything available.
 
Maybe the developers can add support for CsrActiveConfig & BooterConfig maybe it all needs to be re-done with Chimera and Chameleon.
 
a similar problem occurs with mac pro 1.1 and el capitan ... would post link if useful but I worry about breaking rules.
there is a script to swap boot files after install ...
 
So, the third party kexts under EFI/CLOVER directory would not be cached into caches if SIP is enabled. You have to disable SIP then these third party kexts can be cached into the caches. After that, you can re-enable SIP since those third party kexts have been cached into caches.

Even the third party kexts are not placed into /S/L/E, they have to be cached into /S/L/E caches (use the command of "
Code:
sudo touch /System/Library/Extensions
").

Is my description right?
 
So, the third party kexts under EFI/CLOVER directory would not be cached into caches if SIP is enabled. You have to disable SIP then these third party kexts can be cached into the caches. After that, you can re-enable SIP since those third party kexts have been cached into caches.

Kexts that are injected (from EFI/Clover/kexts) are never cached. Only kexts installed to /S/L/E or /L/E are placed in the cache (and even then, only the kexts that are needed by your system).
 
Back
Top