El Capitan should not be booted with rootless=0

First. I believe that Hacking Team (currently offline ROFL) was hacked in late 2014 already, by the Dream Team, and that using rootless=0 as NVRAM/boot-arg is utterly stupid. I mean. Nobody should open ‘a backdoor in OS X’ and rootless=0 helps to protect your filesystem – among others – and so please do not use it with installations that are connected to the Internet. That is all I can say here.

Yes. I can replace your boot.efi with a modified copy of mine and give myself access to all of your files. Trust me. I would never do this, and that is why I urge you to listen to me: Please do NOT boot with rootless=0 Period!!!

Okay. Your hack won’t boot without rootless=0 but hang on. I hear you. This is why I am/will be working with boot loaders developers so that they can fix this. To let your modified kexts load without the need of rootless=0. Without the need of opening a back door. Promised.

Note: You don’t need to replace boot.efi with a legacy boot loader – think Chameleon, Chimera and RevoBoot – to be vulnerable, because boot.efi isn’t used by legacy boot loaders. Not that it really matters, because all* legacy boot loaders are still vulnerable.

Update: RevoBoot and the Enoch branch of Chameleon are no longer vulnerable and can now boot El Capitan without rootless=0 (the ‘all or nothing’ setting.. going away in a next DP).

Update-2: I have not yet been contacted by Clover developers, but then again they might not care about (your) security/privacy.

Update-3: Clover is recently changed and now sets csr-active-config by default similar to rootless=0. Which is, again, utterly stupid.

// CsrActiveConfig
Prop = GetProperty (DictPointer, "CsrActiveConfig");
gSettings.CsrActiveConfig = (UINT32)GetPropertyInteger (Prop, 0x67); //the value 0xFFFF means not set

Note: If Clover has changed, but I missed it, then please let me know so that I can update it here. Thanks!

People who set the NVRAM variable csr-data and/or csr-active-config in a way that it basically disables the System Integrity Protection, that is not in your best interest. What I mean here is that it is better to change as little as possible. Keeping as much protection up and running. Possibly only let unsigned kexts load and let the rest for what it is since that isn't required, and may open a door for exploits.

27 thoughts on “El Capitan should not be booted with rootless=0

      • Hello, pikeralpha. I came across a pretty good dev board named Orange Pi 2 which uses Allwinner H3. Can you make it fully working with Lubuntu? I asked the dev board company named Xunlong to send you their new board for your research and they agreed. If you are interested about their board and the project you can send me your address. I will have them send you one of their board. You can also contact Steven yourself and the contact info is at the bottom of their website. And here is the website: http://www.orangepi.org

      • Hi Jacer,

        I have supported Ubuntu for years, and thus I would try to help you instantly, if only I had the time to start a new project, but that is not possible anymore.

  1. You do realize SJ has had a solution thats works for over a year now called GateBreak right? Allows you to sign your own kexts and does work.

    • What GateBreak does, as far as I can remember, is that it patches the kextcache, kextutil and kexts binaries, to make it accept a different (non-Apple) root certificate. You then re-sign the kext(s) and thus that is something different, but a nice one indeed.

  2. Good advice. I recently had to boot that way to fix a problem (one of Apple’s making) with Java and CS5 under El Capitan. But I did my fix and then re-set and rebooted.

    Also, my understanding is that the ability to set rootless=0 will be removed in the public release of El Capitan.

    • Hi Tony,

      Correct. The rootless argument will be removed later on. In a next DP. People can find references to it in the XNU source code of Yosemite. The latter also shows us how long Apple is working on this feature. The rootless option itself will however still be available, but via a special version of boot.efi

  3. And how can I “load a modified kext without the need of rootless=0. Without the need of opening a back door.”?

    I mean allowing to load a modified (system) kext _is_ a potential back door, right? And we do not only need to load things like FakeSMC, but also patch things like AppleHDA.

    So I am a bit worried and also curious how this will work in the future.

    • It depends on what boot loader you are using. Let’s assume that you are using Clover, which loads boot.efi and then let it do its thing, then you are out of luck. Well. For the time being that is because the Clover developers will need to implement a patching routine for boot.efi to solve this issue.

      If you are using macosxbootloader then you have control over the settings and thus there is nothing to worry about. I only have to patch the source code.

      If you are using a legacy boot loaders, like Chameleon, Chimera or RevoBoot, then there is nothing to worry about since they have full control over the settings. In short. All boot loaders need some sort of patch to workaround.

      • Yeah, I am actually using Clover. So we’ll see how this will be handled then. Thanks for infos and research!

  4. I also heard that this measures do apparently not apply to the kernelcache. So I guess that you could start to place things in the EFI folder and use kext injection with Clover? I am already able to place almost all of my kexts in there and get a booting system. The only exception seems to be AppleHDA898.kext – I am using your “patchless” AppleHDA method and I really like it. But it seems that this kext _must_ be placed in S/L/E, I could not get it to work otherwise. Any insights on that matter? TIA!

    • It probably can’t find a dependency, look in the console log for something like “failed to resolve dependencies,” the kext it’s looking for you could put in the EFI folder. That’s worked for me for most things at least.

    • If you put AppleHDA898.kext in /Library/Extensions then you also need a copy of AppleHDA.kext in the same directory. Tried it myself. Works here in Beta 4.

      Note: The EFI route appears to be a no go in Clover with Beta 4.

  5. Hi there pikeralpha. boot.efi has worked really on both 10.9, and 10.10… and now on 10.11 (so far). I’m running on a genuine MacPro1,1.

    I read somewhere you are not providing support – I understand that. Please take this on board as feedback into your development for boot.efi.

    Also my apologies if this is not the right place to post.

    As Indicated above I have 10.11 running successfully on the MacPro1,1 with boot.efi on a single 1.5TB HDD. So today I thought I’d switch this across to my fusion drive (in the same machine). Needless to say I had no end of trouble. What had worked on 10.10 for the setup of the Fusion drive would appear not to work anymore on 10.11 – so eventually I got a fusion drive created with a recovery partition (that’s the clue). And 10.11 installed via my MacBookPro and working.

    Now I’ve updated the boot.efi in coreservices and standalone/i386 and …. it won’t boot. I get a black screen with an Apple logo and no loading progress bar. I’ve waited for 10 or 20 minutes and nothing. I can successfully reboot back into the 10.11 on the 1.5TB HDD.

    There’s some extra special about the Fusion drive that I haven’t found yet. I have not replaced the boot.efi on the recovery partition (almost wondering if I should do that).

    Anyway… I hope the feedback is valuable. Apologies if I have posted this in the wrong place.

    – David

      • Fusion drive is my own (hybrid). I installed a Crucial M550 (128GB) SSD and am using a 1.5TB Western Digital HDD. I used latest advice from this article to create the Fusion drive http://hints.macworld.com/article.php?story=2014030311173257
        and this I have:

        Davids-Mac-Pro:~ dgwilson$ diskutil list
        /dev/disk2 (internal, physical):
        0: GUID_partition_scheme *1.5 TB disk2
        1: EFI EFI 209.7 MB disk2s1
        2: Apple_HFS El Capitan 1.5 TB disk2s2
        3: Apple_Boot Recovery HD 650.0 MB disk2s3
        /dev/disk3 (internal, physical):
        0: GUID_partition_scheme *128.0 GB disk3
        1: EFI EFI 209.7 MB disk3s1
        2: Apple_CoreStorage Fusion 127.7 GB disk3s2
        3: Apple_Boot Boot OS X 134.2 MB disk3s3
        /dev/disk4 (internal, physical):
        0: GUID_partition_scheme *1.5 TB disk4
        1: EFI EFI 209.7 MB disk4s1
        2: Apple_CoreStorage Fusion 1.5 TB disk4s2
        3: Apple_Boot Recovery HD 784.2 MB disk4s3
        /dev/disk5 (internal, virtual):
        0: Apple_HFS FusionHD +1.6 TB disk5
        Logical Volume on disk3s2, disk4s2
        Unencrypted Fusion Drive

        /dev/disk2 is what I’m currently running El Capitan on (a single HDD).
        I have not performed the trim force enable command.

        I have not edited any boot parameters (at least not to my knowledge).
        nvram -p
        EFIBluetoothDelay %b8%0b
        IdlePML4 %90%da%0e%1c%80%ff%ff%ff
        bluetoothInternalControllerInfo %06%82%ac%05%00%00 ]%00%19%e3%ef%d1%df
        prev-lang:kbd en:15
        SystemAudioVolumeDB %00
        platform-uuid %00%00%00%00%00%00%**%00%80%00%00%**%**%**%**%**
        fmm-computer-name David%e2%80%99s Mac Pro
        bluetoothActiveControllerInfo %06%82%ac%05%00%00%00%00 ]%00%19%e3%ef%d1%df
        efi-boot-device-data %02%01%0c%00%d0A%03%0a%00%00%00%00%01%01%06%00%02%1f%03%12%0a%00%05%00%00%00%00%00%04%01*%00%03%00%00%00%88%c2%e3%0e%00%00%00%00%00%00%04%00%00%00%00%00%d8%12r%db%a6B!A%8c4%9e%e3%ae%0f>%19%02%02%7f%ff%04%00
        SystemAudioVolume @
        efi-boot-device IOMatchIOProviderClassIOMediaIOPropertyMatchUUIDDB7212D8-42A6-4121-8C34-9EE3AE0FxyzzBLLastBSDNamedisk0s3%00
        LocationServicesEnabled %01

        – David

      • OK, new theory.

        Fusion drive looks like this:
        /dev/disk0 (internal, physical):
        0: GUID_partition_scheme *128.0 GB disk0
        1: EFI EFI 209.7 MB disk0s1
        2: Apple_CoreStorage Fusion 127.7 GB disk0s2
        3: Apple_Boot Boot OS X 134.2 MB disk0s3

        The partition “Boot OS X” isn’t on any of my other drives (including the HDD already running El Capitan). So this is special for a Fusion drive.

        With the key contents being:

        Davids-Mac-Pro:CoreServices dgwilson$ ls -la
        total 672
        drwxr-xr-x 9 root wheel 306 19 Jul 22:46 .
        drwxr-xr-x 3 root wheel 102 19 Jul 19:54 ..
        -rw-r–r–@ 1 root wheel 569 19 Jul 22:46 .disk_label
        -rw-r–r– 1 root wheel 8 19 Jul 22:46 .disk_label.contentDetails
        -rw-r–r– 1 root wheel 2261 19 Jul 22:46 .disk_label_2x
        -rw-r–r– 1 root wheel 38 19 Jul 22:46 .root_uuid
        -rw-r–r– 1 root wheel 5209 19 Jul 22:46 PlatformSupport.plist
        -r–r–r– 1 root wheel 478 19 Jul 22:46 SystemVersion.plist
        -rw-r–r– 1 root wheel 313344 19 Jul 22:24 boot.efi

        I’m guessing I need to edit the file PlatformSupport.plist
        … and maybe change the boot.efi (although it’s size is a match for the pike one).

        I’m unable to mount the partition read/write.😦
        mkdir /Volumes/dgw
        sudo mount -o rw -t hfs /dev/disk0s3 /Volumes/dgw

        thinking I have to look at doing things in single user mode???

      • Another piece of information on the Fusion drive installation.

        I destroyed and rebuilt the fusion drive, and performed a clean install of 10.11 over Firewire … and performed all of the beta release updates. Replaced the boot.efi files and still no boot.

        So this evening I thought… I should do a disk first aid check…. I got it to run after I started with the “FusionHD” unmounted.

        And I thought I’d perform a bless. Interestingly that error as well.

        sudo bless –folder /Volumes/FusionHD/System/Library/CoreServices/ –file /Volumes/FusionHD/System/Library/CoreServices/boot.efi –setBoot
        Could not set boot device property: 0xe00002bc

        Seems to suggest that something is wrong with the underlying fusion drive????

        – David

  6. Wouldn’t the system with rootless=0 not be any less secure than running Yosemite or older? Am I misunderstanding this?

    • SIP was first introduced in Yosemite (xnu-2782.1.97) but will be fully enabled in El Capitan, to protect you from running into trouble, and thus running it with rootless=0 is a step backwards. Like not applying patches to close security/privacy related issues that Apple and others have found so far.

  7. I hate Apple for this nuisance, I’m sorry they judge users as utter retards, who will literally accept anything to run on their machines. Just to have to reboot into recovery to turn off this feature, so I can actually load the kernel modules which aren’t signed by our trusted root signing authority overlords. Thanks “apple” for making darwin enforce some crappy “special” isolation feature which disables filesystem modification to certain hard coded inodes and usage of “special” sys calls. Looks like I am switching to Debian on my laptop, and also thanks for making kernel module development just that much more of a nuisance

  8. Hi Pike,

    i am using your boot.efi with Yosemite on my MacPro 2,1. Nerver had any problems except after Updates from Apple of course. Anyway, copied your boot.efi over the new ones on both locations. Done.

    First of all: Thank you for your work.

    Now i have installed El Capitan GM. Currently i’m using the boot.efi from http://forums.macrumors.com/threads/2006-2007-mac-pro-1-1-2-1-and-os-x-el-capitan.1890435/page-13 , and its working. But it boot my Mac in verbose-mode, what i dont want. So, may i ask you how is the progress on a new boot.efi like for Yosemite and can we expect one?

    Kind regards

    • Hi,

      First off. Welcome here. Good to hear that. Thanks!

      Now. The verbose boot mode is enabled, by default, as an aid. To help me fix bugs. Remember this. I don’t have an old Mac Pro, so I am basically driving blind. I thankfully rely on the feedback I get from Mike and Splifingate. A big thanks also to Peter Holbrook, for all his compiling runs. I tell you. That takes some time and energy. It’s not just me working on it. We’re a team. Luckily, because otherwise this would not have been possible. But in short. Yeah. We are getting closer and closer to something really good. Thanks to all people involved… so stay tuned😉


      • Hi Pike… Thanks mate. But weird to read that you do all of this in a blind flight. Sounds not so easy… anyway, its working🙂 Without you i have to stay on OS X Lion… Damn Apple, why they do that?!

        Kind Regards

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s