Notes from Thursday Security Lab

System Integrity Protection



Question:


Will disabling SIP be available as a choices .XML at install time for the 10.11 OS? If not, what mechanism will be provided for automatic disabling of SIP for use with automated imaging processes for machines?


Pain point: Not every environment will be able to access Internet Recovery. At the same time, straight cloning of existing disks is problematic.



Answer:


SIP is always off in the Recovery environment and the Installer environment. While booted from those environments, you will be able to make changes to a boot disk which is otherwise protected by SIP.


SIP-protected files will still appear as "restricted" when listed with ls's -O, but they can be renamed, moved, deleted or changed.


There will be a command line tool to disable SIP in the Recovery environment, separate from the current GUI tool. The GUI tool is in fact going to disappear in favor of the command line tool. This change will likely appear in Developer Beta 2 or Beta 3; check the release notes.



Question:


The /System/Library/CoreServices/DefaultDesktop.jpg symlink is locked by System Integrity Protection (SIP) and cannot be modified. Being able to change this file will allow an admin to change the default picture for the machine. Can this be fixed? I've filed a bug on this, bug ID: 21327831


Answer:


That's a bug. Thanks for making us aware of this, as /System/Library/CoreServices/DefaultDesktop.jpg shouldn't be included in SIP's protection. This will likely be fixed in Developer Beta 2.



Question:


There is a nvram boot-args command available in Developer Beta 1 which can disable SIP when run with root privileges:


nvram boot-args="rootless=0"


Will this option of disabling SIP also be available in the El Capitan release version? Or is this strictly for the Developer Builds?


Answer:


This nvram boot-args command will be going away. It will not be available in the El Capitan release version and may disappear before the end of the Developer Betas. Keep an eye on the release notes for future Developer Betas.

Question:


With regards to bless --netboot going away, what happens if you use ARD and choose the "Startup Disk" task to remotely netboot a machine?



Answer:


That's a really good question! We haven't tested that, please test and file a bug if it doesn't work.

Replies

Update about the Apple Remote Desktop-related question. Tim Sutton gave it a try and it apparently works:


<tvsutton> I just tried it in ARD, choosing the Startup Disk task to point the Mac to an NBI that's not my default image, on another subnet (and we have IP helpers in place for bootp and DHCP), and it worked.

Note that as of the current Beta, the bless command pointing to an explicit server ip/nbi still seems to work in our environment, which does not have any IP helpers (and doing a bless --getBoot --verbose confirms the same EFI boot device string is being written as in 10.10).


The question is, is ARD supposed to work in this environment without helpers once bless is neutered?


I would not be surprised if ARD is simply calling bless under the covers on the client to do what it does, so this will definitely need to be retested once they yank the functionality out of bless.


IP Helpers are intentionally not used in our environment -- we don't want our netboot servers being advertised or visible via option/command-N unless an adminstrator explicitly chooses to netboot a client (almost always remotely, usually via ARD). If we are forced to alter infrastructure to enable helpers, this will actually create additional support headaches. IMNSHO the threat of bad actors using a remote netboot server would be better addressed at the network/instutional firewall instead of crippling functionality at the client...

The following was done in our environment:

Environment:

Server and client on different subnets

HelperIPs configured on network equipment

Client: iMac9,1 with 10.11 (15A178w)

Server: Production Netboot Server 10.8.2 - NBI OS 10.10.3

"n" key down on boot

- Held "n" key down on boot

- Booted to default NBI

"option" key down on boot

- Held "option" down on boot

- No NBIs presented but thinking this is due to the age of EFI on the computer.

Startup Disk selection of netboot

- Logged in as local admin

- Netboot image(s) visible and selectable

- Booted to NBI

bless to broadcast

- No user logged in

- Sent 'bless --netboot --server bsdp://255.255.255.255 --nextonly' via ARD Unix command

- Booted to NBI

Set Netboot via ARD menu

- Set startup disk to available NBI in "Set Startup Disk" option of ARD and rebooted (ARD run from the same subnet as the client)

- Booted to NBI

Does this explain why SuperDuper! is blocked from performing a Backup?

For clarity, we use a command like the following issued via ARD, which I understand is effectively bypassing bdsp altogether (netboot servers are not visible via option/cmd-N outside the server's subnet, by design):


bless --netboot --booter tftp://<server_ip>/NetBoot/NetBootSP0/<image_name>.nbi/i386/booter --kernel tftp://<server_ip>/NetBoot/NetBootSP0/<image_name>.nbi/i386/mach.macosx --kernelcache tftp://<server_ip>/NetBoot/NetBootSP0/<image_name>.nbi/i386/x86_64/kernelcache --options "rp=nfs:<server_ip>:/private/tftpboot/NetBoot/NetBootSP0:<image_name>.nbi/NetInstall.sparseimage"

When the maintenance task ends (generally a DeployStudio workflow which either reimages the machine or wipes the drive), the DS runtime sets the startup disk back to local. Our 500 systems are reimaged at least once a year -- some public locations get reimaged twice yearly.

Complementary: http://asciiwwdc.com/2015/sessions/706