Home Forums FineTunedMac Community Lounge rootless

having seen this brought up in another thread I decided to go looking for more information on it. Lots of people parroting the same few sentences from Apple, but very little actual explanation for WHAT it is and HOW it works. So I finally ran into this and thought I'd share it:

http://www.quora.com/Can-someone-elaborate-on-the-OS-X-10-11-feature-called-Rootless

It's much more than just an iOS thing. The gist is it's a new file attribute that can be set, just like Locked or Invisible, that when set, will only allow access by code whose chain of authority comes from code signed by Apple. In a way it's a bit like the SCHG flag, the "super lock", that you can set, but cannot UNset, even as root. (to remove SCHG, you have to reboot, and drop into single user mode and change it then - once kernel mode has gone up a notch during boot, a process that cannot be reversed, SCHG cannot be unset even by root)

So Apple is expected to use this to protect key files from modification/replacement as part of the "iOS rooting" process. If someone finds an exploit to get root, it will no longer simply be a case of making the usual file system changes - the "rootless" protection of those key files will also have to be dealt with. This means that it will be necessary to find an exploit in a piece of software signed by Apple, not just any exploit such as in Java or Flash. "Getting Root" isn't enough to root the phone anymore.

Apple has essentially raised the bar on the trust level when making changes to critical system files. I don't think I like where that's going, because it locks ME out of my own stuff. I can't just "sudo -s" or login as root and get a root prompt and go make a change/fix that I want to. It really nerfs root, to the point where it's arguably NOT root anymore. It's not root anymore just the same as I, as a system administrator, aren't root. The difference being I can GET root, but root isn't the root it used to be anymore...

That clarifies (thanks) but raises more questions.

Does that mean in a desktop/laptop Mac environment only apps from Apple's App Store will be protected in this manner? Can Apple sign a piece of software, return it to the developer to distribute outside the App Store, and not have the rootless status changed?

I'm thinking of the issues with backup software that were raised by others in the related thread.

It's not apps that are protected, rather


Edit: The issue with backup software is that it can't deal with those protected folders to back them up, or, in the case of SuperDuper, see dkmarsh's post here.

I can understand WRITE protecting data from root, that has a very plausible "prevent me from shooting myself in the foot" rationale, but preventing me from reading it seems to demand a different justification and explanation. I suspect a lot of DRM makers are salivating at this prospect.

System cloning software can make a backup just fine in the presence of "rootless" files and folders, as long as the flag is only preventing changes. The backup, as restored, will likely just lack the Rootless flags. (unless root can SET the flag... a bit like how root can set SCHG but not so easily clear it)

OK, makes sense. Thanks.

You nailed it! A cloned system, or one that was restored from a clone, would not have the SID activated and therefore vulnerable. As I understand it there is an on/off switch but it can only be run when booted from the Recovery Drive. Strictly limiting the set/unset routine to the Recovery Drive should shield it from all but the most obvious exploits — even though it would still be vulnerable to clever social engineering exploits (a.k.a. trojans). It would possible that after cloning or restoring from a clone the user then boots from the Recovery Drive and resets the flags, then boots back into the system. The concern would be that too many (most?) users will not follow through and reset the SID leaving their systems unprotected after any cloning operation. (As long as the drive containing the clone is mounted there would be nothing to prevent malware from infecting a clone whose SID was deactivated.)

Sounds like a good possible solution to me, but perhaps more easily said than done.

I am not prone to paranoia, but with some of the malware that is coming out these days I am coming to the conclusion it is better to be paranoid than sorry.