SIP (System Integrity Protection)

That's some serious changes. We rely on the ability to remote netboot.

I don't fully understand the logic.

A remote netboot attack would require a netboot server setup on an accessible network. Are they thinking that someone would setup a public facing Netboot server and remote netboot clients to that? That would be painfully slow on most connections.

What about locally holding "n" with HelperIPs? Or booting to the recovery partition and turning it off? Or Target Disk Mode? Or hooking up an external drive to boot from? Closing off that one method seems to punish the good.

I'm not sure how removing the ability to bless --netboot helps secure things if someone can also just press N. Does bless --netboot get around firmware passwords?

Yes, I use this all the time on my lab machines that are locked with a firmware password. Using bless I can reboot them to netboot.

I'm thinking they're looking at it as a escalation to a circumvention process for SIP:

• Something happens, BadGuy process gets root/sudo
• Uses it to then bless --netboot a remote BadGuy automation toolset
• Triggers system reboot

Then the machine reboots to the netboot volume, which bypasses the SIP protections since it could be a non-10.11 netboot without SIP itself - then modifies the local /System/whatever structure. Then re-blesses back to internal and reboots. SIP circumvented.

I just spoke with another engineer for confirmation.

If you have helper statements, you can still use Startup Disk to boot into a NBI for imaging purposes.

They have an internal solution/idea for bless, but they need more impact data to understand whether they will work on it or not.

As far as writing to /System with a package, it's still unknown what areas you will be able to write to with a Developer signed pkg. Preinstall/postinstall actions should still work. You cannot sign a package with a self signed certificate and import it into the System Keychain.

I was told to file a RADAR regarding SIP blocking /Library/Desktop\ Pictures .

That's some action movie stuff there. Anyone seen The Net?

I actually used this method to install VMWare Tools on the 10.11 VM. Had to boot it to a 10.10 NBI to install the tools. But our Netboot image is password protected anyway. This seems a little strong handed.

"I was told to file a RADAR regarding SIP blocking /Library/Desktop\ Pictures"

Not seeing that here. I can create a new file in that directory using sudo.

If they put in a mechanism for an SIP-protected embedded whitelist of netboot targets, modifiable during imaging or something, I could see that as an acceptable workaround in combination with locking down bless.

But seriously - too many enterprises have automated "boot to alternate OS servicing image/tool" workflows.

And MDM could trigger the reboots in an "approved" way with DEP - but now you're trading something you have to invest serious $$$ and time into for what bless does now.

Neither Rich nor I could do it in our VM's, using Finder/Terminal.

How did you do it?

I can 'sudo touch file' in /Library/Desktop Pictures/

homeadmins-Mac:~ homeadmin$ cd /Library/Desktop\ Pictures/
homeadmins-Mac:Desktop Pictures homeadmin$ touch file
touch: file: Permission denied
homeadmins-Mac:Desktop Pictures homeadmin$ sudo touch file
Password:
homeadmins-Mac:Desktop Pictures homeadmin$ ls -l file
-rw-r--r--  1 root  wheel  0 Jun  9 14:01 file

/Library/Desktop Pictures itself is not blocked, but try modifying /Library/Desktop Pictures/El Capitan.jpg, which is what /System/Library/CoreServices/DefaultDesktop.jpg points to.

I was not able to delete /Library/Desktop Pictures/El Capitan.jpg or remove it in my testing. I could make a copy of the file, and was even able to make a copy of it inside of /Library/Desktop Pictures.

This I can replicate.

Odd choice of protected files.

I'd think it'd be just as easy to

if [ ! "$desktop_picture" ]

then

use solild color

fi

RADAR reported:

21308772

openradar dot me id=5054091155734528

Radar reported: 21310286

openradar dot me id=4935225620561920

The issue you describe is pretty different from the one Eric mentioned!

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.