SIP (System Integrity Protection)

Apple's new El Capitan feature SIP (System Integrity Protection) aka "rootless" will have some interesting impacts that will impede workflows for administrators.


- If you Netboot across subnets, you will no longer be able to use bless. Apple's view is if someone can target a machine to boot to a non 10.11 OS, they can bypass SIP. This will prevent any unathorized boot methods.


- You will be able to write to certain privileged folders through the use of a package signed with a valid Apple Developer code signing certificate.


More soon on SIP if I can find the right engineer.

Replies

I am running into this now trying to edit /sbin. I can edit /etc, but not /sbin. Logged in as root. I can understand having these limitations as Admin as thats the default user created, but not Root! But I guess if there is an exploit to get to root easily then maybe its a good thing. But I don't get the logic with the lock down on Netboot either. I do the same as hfike.


To my understanding you can disable SIP by using a utility on Recovery Partition, but I have haven't tried to find it yet.

Well that was easy......boot to Recovery Partition and right under the Utilities menu is Security Configuration. Simple check box.

Easy for just one machine but hands on is the _only_ way to change that setting. Our sneakernet has been retired for a while now. I'm not a fan of turning it off yet, either. This isn't going anywhere anytime soon. It'd be better to address it's limitations and try to help excelerate it's maturity than to ignore it, especially as it is brand new. Feedback, feedback, feedback, and impact, impact, impact.

I do agree!

Wouldn't FV2 be a mitigation for this? The attacker that is NetBooting to another system presumably wouldn't be able to bypass the FDE login and the internal system disk wouldn't be modifiable unless it could be decrypted.

Our site is one that will be majorly impacted if netbooting across subnets is broken. We routinely use this method to reimage an ever-growing number of lab machines (currently ~500).


What the best way now to provide feedback/impact data to Apple regarding this?


(As of the current 10.11 beta I am still able to bless/netboot to our imaging server (Nothing to RADAR yet))

There has been chatter today that netbooting across subnets will work properly if the network is setup with HelperIPs. Our environment is setup with HelperIPs so it should be easy to see if blessing to a broadcast IP or direct server works or not. I plan on testing this on Thursday to confirm/deny. Regardless since there's no official documentaiton on this yet I'd recommend filing a bug with the impact on your environment.

the impact for us is over 1200 lab machines that get re-imaged every year. Add to that the potential to netrestore any of our 1000 or so staff machines if they need a ****-and pave.

Disabling SIP can also be acheived by:


sudo nvram boot-args="rootless=0”

For now. Don't expect that to exist in ElCap's final form.

Spoke with an engineer regarding this yesterday. They don't anticipate this option being removed for the final release (similar to Yosemite's signed kext method).


I also asked whether this option would be deprecated next year (again similar to the kext signing) and they did not anticipate it being deprecated. Who knows what happens between now and OS X 10.12.

So, I've noticed that SIP restricts write access do System/Library/LaunchDaemons.

Question is... How would I go about changing the default SSH port? In previous versions of OS X, I would just edit the ssh.plist file in this directory. Now, with SIP, this is no longer possible. What's the politically correct way of doing this on a SIP enabled Mac?

If they already have root on the booted system I think authenticated restart would get around FilveVault 2.


sudo fdesetup authrestart


OS X: Macs that support authenticated restart with FileVault

https://support.apple.com/en-us/HT202918

And today the story has changed. The argument will be taken away either before final release or once released to public.

You can modify files in /private/etc so this would be the recommended approach. Only the /etc symlink is protected by SIP.