Hackers? More like tweakers or power users here at macrumors for the most part.
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Rootless kernel level protection
- Thread starter tarf
- Start date
- Sort by reaction score
oatman wrote above:
"It is in the OS... You cannot modify or delete system files even with SUDO"
But there will be cases where administrators need this ability, regardless.
EDIT:
I had originally posted:
"Does a terminal command exist to override "rootless"?"
... but see that some capable users have already answered my question!
Thanks!
"It is in the OS... You cannot modify or delete system files even with SUDO"
But there will be cases where administrators need this ability, regardless.
EDIT:
I had originally posted:
"Does a terminal command exist to override "rootless"?"
... but see that some capable users have already answered my question!
Thanks!
Last edited:
Even simpler, this command will restart with rootless disabled:
Code:
sudo nvram boot-args="rootless=0";sudo rebootEdit: In case the boot argument method stops working in future versions, here's how to disable it through Recovery as of the first beta. Boot into Recovery (start up holding down down Command-R until the Apple logo appears), and select "Security Configuration" from "Utilities" on the menu bar. Uncheck "Enforce System Integrity Protection", click "Apply Configuration", click "Apply" on the resulting prompt, and restart. Rootless will now be disabled.
Last edited:
Wait, WHAT? Surely there's no apps - at all - that can and will be able to disable rootless? If so then what's the point of it being there at all. Also, IF (and I highly doubt this is the case) an app COULD disable rootless, would you get any kind of warning or notification before it happens?
"command line tool"? I assume you mean the boot argument. Anyway, I unchecked Utilities > Security Configuration > Enforce System Integrity Protection in Recovery and it does have the same effect as the boot argument.
I just re-watched the Platform State of the Union session that included this info. He said the developers would be able to develop kext extensions to ensure compatibility with SIP in Xcode but for those that can't work with SIP, Apple will provide an option via recovery partition tool to disable SIP. When he said this, the slide said simplified developer workflow as in there would be a workflow to disable SIP by the devs, so I got confused here. I believe you can only disable SIP via the recovery partition and you're correct, it would stupid for Apple to allow anyone to disable SIP like this.
See my post here. As others mentioned, maybe they will remove the command line option, but leave the recovery GUI option to disable rootless?
You can still edit files in /etc. you can't put things into /usr/bin but /opt, /usr/local are both fine. I will need to check but I suspect there are *.sb files listing specific things that are or are not allowed.
I took a look, and there's a /System/Library/Sandbox/rootless.conf that defines what is blocked. The first column is the process (or wildcard) which can edit files there. The second is what's blocked.
So the following is blocked: /System, /usr, /bin. But there are exceptions allowing access to /usr/local and a bunch of other things. Note at the bottom that /etc, /tmp, and /var are blocked, but those are only symlinks to the actual directories in /private. So you can still edit anything under those directories, you just cannot change the symlink itself.
So the following is blocked: /System, /usr, /bin. But there are exceptions allowing access to /usr/local and a bunch of other things. Note at the bottom that /etc, /tmp, and /var are blocked, but those are only symlinks to the actual directories in /private. So you can still edit anything under those directories, you just cannot change the symlink itself.
Code:
/System
* /System/Library/Caches
booter /System/Library/CoreServices
* /System/Library/Extensions
/System/Library/Extensions/*
UpdateSettings /System/Library/LaunchDaemons/com.apple.UpdateSettings.plist
* /System/Library/Speech
* /System/Library/User Template
/bin
dyld /private/var/db/dyld
/sbin
/usr
* /usr/libexec/cups
* /usr/local
* /usr/share/man
# symlinks
/etc
/tmp
/varIn the Security session at WWDC, Apple said they're removing that boot-args command and the option to disable SIP will be available via the recovery OS's utility to change the security options.
They also mentioned such a change via Recovery OS will push it into nvram and will rename persistent across OS installs, so it's a one-time change.
Last edited:
I have the same problem. It only works for the second SSD but not for the system SSD.
Also tried it deactivation from booting into the recovery partition (internal+external), in the terminal and in the tools.
But all that does only work for the other SSD.
Last edited:
What about removing your external SSD and using only internal SSD to see if you can disable rootless?
Does Rootless also cripple Single User Mode or have they decided to be reasonable and exclude it from these heavy-handed shenanigans?
I can confirm this
I have two drives in my MBP and the GUI option in recovery only disables rootless my drive that contains bootcamp and a data partition, this two partitions show up as "rootless enabled - NO" but on my system drive, with only one partition its, "rootless enabled - YES"
*Edit - If we can't access system files that will supremely suck
If you remove all your external drive, and try to disable rootless, you may get something new. I have only one drive with boot camp. I use preview recovery partition disabled rootless successfully and reinstalled paragon ntfs software again.
They did not even mention the command-line option to accomplish this, but recommended using the Recovery OS. Root cannot be trusted after all. From the developer session I understood that the latter method is going to stay for the time being, specifically to allow kext developers to test their modifications prior to applying for a signature (as kexts have to be signed since Yosemite). However, I think the tendency is pretty obvious and the frankness with which they approached the subject makes it more or less clear that third-party system modications are a thing of the past as far as Apple is concerned.
