New SIP management command line tool

Here's a script I've written for reporting on SIP's status. It's not working entirely like it should in Beta 7, thanks to Beta 7's csrutil reporting the wrong status if it's disabled*, but it should be good enough otherwise for reporting.

#!/bin/bash


osvers_major=$(sw_vers -productVersion | awk -F. '{print $1}')
osvers_minor=$(sw_vers -productVersion | awk -F. '{print $2}')


# Checks to see if the OS on the Mac is 10.x.x. If it is not, the
# following message is displayed without quotes:
#
# "Unknown Version Of Mac OS X"


if [[ ${osvers_major} -ne 10 ]]; then
  echo "Unknown Version of Mac OS X"
fi


# Checks to see if the OS on the Mac is 10.11.x or higher.
# If it is not, the following message is displayed without quotes:
#
# "System Integrity Protection Not Available For" followed by the version of OS X.


if [[ ${osvers_major} -eq 10 ]] && [[ ${osvers_minor} -lt 11 ]]; then
  echo "System Integrity Protection Not Available For `sw_vers -productVersion`"
fi


if [[ ${osvers_major} -eq 10 ]] && [[ ${osvers_minor} -ge 11 ]]; then

# Checks System Integrity Protection status on Macs
# running 10.11.x or higher


  SIP_status=`/usr/bin/csrutil status | awk '/status/ {print $5}' | sed 's/\.$//'`


  if [ $SIP_status = "disabled" ]; then
      result=Disabled
  elif [ $SIP_status = "enabled" ]; then
      result=Active
  fi
   echo "$result"
fi

*Bug report filed for this issue. Receiving System Integrity Protection status: enabled (Custom Configuration) is confusing. The Custom Configuration is that System Integrity Protection is disabled, but the status message may cause the reader to believe that System Integrity Protection’s protection is still enabled.

In poking at the changes made to the SIU framework for my own project's needs (AutoNBI) I noticed some SIP-specific allowances that were added to modify Netbooting permissions for the target system. This indicated to me that NetInstall and NetBoot images by default have the 'csrutil' tool included in a Recovery mode-like way, which I have been able to verify since then. This means thatcsrutil is able to make changes from a NetInstall/NetBoot environment which thus far seemed to only possible from the Recovery partition. The relevant code is from 'addBSDPSources.sh' which adds a list of IPs from a file named 'bsdpSources.txt' in the 'Packages/Extras' folder to the list of whitelisted Netboot IPs on the host being imaged. This may be point towards a general best practice for Mac Admins' workflows in order to minimize the impact of restricted 'bless' functionality in normal runtime mode OS X.

extrasDir="/System/Installation/Packages/Extras"
theFile="${extrasDir}/bsdpSources.txt"


if [ -f "${theFile}" ]; then
  while read ENTRY
  do
  # Run csrutil on each entry in the file
  csrutil netboot add "${ENTRY}"
  done < "${theFile}"
fi

Hey

Thank you both for digging in to this!!!! : )

C

I am looking for advice. Here is what I did:

• Started with a MacBook Pro 17" (early 2008) running "production" Yosemite 10.10.5 with the latest patches and updates.
• Installed OS X 10.10 Yosemite on an external hard drive, then updated it to the latest. (So the Recovery Partition would be the latest version.)
• Used Carbon Copy Cloner to clone the production Yosemite to the external drive as a backup. Removed the external drive and rebooted.
• Ran the OS X 10.11 El Capitan GM Candidate installer on the internal drive Yosemite. It installed El Capitan as expected.

My goal is to test various "questionable" old software (e.g., Timbuktu Pro 8.8.5) under El Capitan.

HERE IS MY QUESTION:

If I want to restore the "production" Yosemite to the internal drive, should I run "csrutil disable" or "csrutil clear" first to restore the nvram boot-args to a known state before wiping the drive and restoring Yosemite? (If so, which should I run - "disable" or "clear"?)