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!