csrutil updated in DP7

New version

The seventh Developer Preview (build number 15A263e) comes with version 13 with a couple of alterations.

New allowed netboot source list

csrutil
usage: csrutil
Modify the System Integrity Protection configuration. All configuration changes apply to the entire machine.
Available commands:

clear
	Clear the existing configuration. Only available in Recovery OS.

disable
	Disable the protection on the machine. Only available in Recovery OS.

enable
	Enable the protection on the machine. Only available in Recovery OS.

status
	Display the current configuration.

netboot
	add <address>
		Insert a new IPv4 address in the list of allowed NetBoot sources.
	list
		Print the list of allowed NetBoot sources.
	remove <address>
		Remove an IPv4 address from the list of allowed NetBoot sources.

Improved output of csrutil status

I’m sure that this is something that people have been waiting for

csrutil status
System Integrity Protection status: enabled (Custom Configuration).

Configuration:
	Apple Internal: disabled
	Kext Signing: disabled
	Filesystem Protections: enabled
	Debugging Restrictions: enabled
	DTrace Restrictions: enabled
	NVRAM Protections: enabled

With netboot setup you get something like this:

System Integrity Protection status: enabled.

Allowed NetBoot sources:
    10.10.0.1
    10.10.0.2
    10.10.0.3
    10.10.0.4
    10.10.0.5

At least now you know what is enabled, and what not – on a Mac. I like it. Much better like this. But on a hack on the other hand this should be taken with a grain of salt. The reason for this is that the output of csrutil status may lie. That is. It may tell you that SIP if fully enabled, when in fact it is not. This because boot loaders may get out-of-sync with the setting.

Additionally. You may see this note

This is an unsupported configuration, likely to break in the future and leave your machine in an unknown state.

There is also a new NVRAM variable called csr-data. No data. Just <> May only be there after I changed the configuration. I’m not sure yet.

Update: This variable is used for netboot setups.

Here is an example of the output you’ll get with: nvram -p

<dict><key>netboot-sources</key><array><string>10.10.0.1</string><string>10.10.0.2</string><string>10.10.0.3<string>10.10.0.4</string><string>10.10.0.5</string></array></dict>%00

For this I ran: sudo csrutil netboot add 10.10.0.x

To remove the last IP4 address you enter: sudo csrutil netboot remove 10.10.0.5

You can verify if the change(s) were done correctly with either: csrutil netboot list or csrutil status.

Edit: csrutil status first reads csr-data and if that is zero (0) then the value of csr-active-config is used.

And last but not least. This is what I get – from the command prompt on a hack – with:

csrutil enable --no-internal
csrutil: failed to modify system integrity configuration. This tool needs to be executed from the Recovery OS.
sudo csrutil enable --no-internal
Successfully enabled System Integrity Protection. Please restart the machine for the changes to take effect.
sudo csrutil enable --without kext
csrutil: requesting an unsupported configuration. This is likely to break in the future and leave your machine in an unknown state.
Successfully enabled System Integrity Protection. Please restart the machine for the changes to take effect.
sudo csrutil enable --without fs
csrutil: requesting an unsupported configuration. This is likely to break in the future and leave your machine in an unknown state.
Successfully enabled System Integrity Protection. Please restart the machine for the changes to take effect.
sudo csrutil enable --without debug
csrutil: requesting an unsupported configuration. This is likely to break in the future and leave your machine in an unknown state.
Successfully enabled System Integrity Protection. Please restart the machine for the changes to take effect.
sudo csrutil enable --without nvram
csrutil: requesting an unsupported configuration. This is likely to break in the future and leave your machine in an unknown state.
Successfully enabled System Integrity Protection. Please restart the machine for the changes to take effect.
csrutil report

This command is also still supported. Also. There is a launch daemon called com.apple.csrutil.report.plist in /System/Library/LaunchDaemons and that is configured for a timed job i.e. set to run on the fourth day of the week at 3:20 Here is the content of the plist:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>Label</key>
	<string>com.apple.csrutil.report</string>
	<key>ProgramArguments</key>
	<array>
		<string>/usr/bin/csrutil</string>
		<string>report</string>
	</array>
	<key>StartCalendarInterval</key>
	<dict>
		<key>Minute</key>
		<integer>20</integer>
		<key>Hour</key>
		<integer>3</integer>
		<key>WeekDay</key>
		<integer>4</integer>
	</dict>
</dict>
</plist>

See also: my csrstat.c to show CSR/SIP status and Apple’s Configuring System Integrity Protection

Update: When I run csrutil status, then I get a Segmentation fault: 11 No error with sudo.

Advertisements

12 thoughts on “csrutil updated in DP7

  1. I use csrutil status and I have same results:
    Last login: Thu Aug 20 16:32:48 on ttys000
    crushers-iMac:~ crusher$ csrutil status
    System Integrity Protection status: enabled.
    crushers-iMac:~ crusher$

  2. Pingback: Michael Tsai - Blog - System Integrity Protection Documentation and Bugs

  3. Pingback: SIP about to change once more? | Pike's Universum

  4. Pingback: csrstat.c to show CSR/SIP status | Pike's Universum

  5. Pingback: 關閉 OSX 10.11 SIP (System Integrity Protection) 功能 | 可丁丹尼@一路往前走2.0

  6. Hi: I did csrutil enable –without kext and it gave me this error:

    “requesting an unsupported configuration. This is likely to break in the future and leave your machine in an unknown state.”

    Not a code expert or anything like that. I’m just trying to get my iSCSI initiator to work (Drobo) which throws out a “invalid signature” error in console when SIP is enabled. I’d like to bypass signature validation on that one specific kext (the iSCSI driver text), but I’d settle for bypassing it on ALL the kexts.

    My question is, given the warning above, will bypassing the KEXT protections render my system unworkable in the near future if, say, they decide to change something with SIP?

    Thanks, in advance, for any insights.

    macguyincali

    • Hi,

      Once unsigned kexts are included in the kernel cache, then you can disable the insecure SIP setting for unsigned kexts (after a reboot or two).

      You may also want to add the Kernel Cache (link) in /L*/P*/SystemC*/com.apple.Boot.plist to stop kernelcache updates from excluding unsigned kexts again, and add a new directory in the protected /System/Library directory, like MyKernelcache for example, and copy the newly created /S*/L*/Kernelcache/kernelcache to the new directory. For this you temporarily need to lift filesystem protection, but after the changes have been made, you can enable SIP again. Without restriction, until the next OS update or installation of new drivers.

      Good luck!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s