As my colleague @quovadimus82 has previously documented, OS X El Capitan includes a new option for showing and hiding the menubar.

This option is available in System Preferences, in the General preferences.

It is also possible to use the defaults command to set the menubar’s behavior. Here’s how you can set the menubar to be hidden and unhidden using defaults:

To hide:

defaults write NSGlobalDomain _HIHideMenuBar -bool true

To show:

defaults write NSGlobalDomain _HIHideMenuBar -bool false

Once run, logout and log back in to see the change in behavior. Alternatively, you can run the following command as the logged-in user to restart Finder and show the changes:

killall Finder

For those who wanted a copy of my security talk at JAMF Nation User Conference 2015, here are links to the slides in PDF and Keynote format.

PDF – http://tinyurl.com/JNUC2015SecurityPDF

Keynote – http://tinyurl.com/JNUC2015SecurityKeynote

@clburlison has discovered that you can take screenshots of the OS X login window on OS X El Capitan using OS X’s keyboard shortcuts for making screenshots.

This appears to be a new feature of El Capitan, as I was unable to reproduce this behavior on OS X Yosemite.

In my testing, I’ve verified that using the following commands work:

• Take a screenshot of the entire login window: Command+Shift+3
• Take a screenshot of a user-selected area of the login window: Command+Shift+4

The screenshot file(s) will then appear on the desktop of the next user to log in.

To distinguish these login window screenshots from screenshots taken while logged in, the login window screenshots’ filenames begin with LW.

I’ve updated the create_vmware_osx_install_dmg.sh script that I had previously posted about here. The script now includes support for El Capitan, so the script can now be run on 10.7 – 10.11 to create custom OS X 10.7.x, 10.8.x, 10.9.x, 10.10.x and 10.11.x installers for VMware Fusion and VMware ESXi. See below the jump for the details.

Downloading the script and support files

Download a .zip archive containing all needed files from my GitHub repo. This will give you both the create_vmware_osx_install_dmg script and a directory named support which contains files that the script will be copying into the completed disk image.

Both the create_vmware_osx_install_dmg script and the support directory must be stored in the same directory in order for the script to work properly.

Once you have the .zip archive download and uncompressed, go into the support directory and unzip the First_Boot_Package_Install.zip file. First Boot Package Install.pkg is used by the script so it’ll need to be unzipped and prepared before running the script.

Note: The First Boot Package Install.pkg included with this script will automatically install all available Apple software updates following the OS installation, but provide no other customization for the VM.

Creating a customized first boot package

If you want to have a first boot package that installs other packages at first boot, I’ve written a tool named First Boot Package Install Generator.app that will generate a first boot package that works with this script.

NOTE: The customized OS X installer will have an upper limit of 350 MBs of available space for added packages. This is sufficient space for basic configuration, payload-free or bootstrapping packages, but it’s not a good idea to add Microsoft Office or similar large installers to this installer.

For details on how to use First Boot Package Install Generator.app to generate your first boot package, please see this post:

https://derflounder.wordpress.com/2014/10/19/first-boot-package-install-generator-app/

When using a first boot package with this script, the script has the following hard-coded requirements:

1. That the first boot package is named First Boot Package Install.pkg
2. That the first boot package is stored in the support directory.

Running the script to create a customized OS X install .dmg file

Once you have the first boot package available and configured to your preferences, run the create_vmware_osx_install_dmg script with two arguments:

1. The path to an Install OS X.app or the InstallESD.dmg contained within.
2. A directory to store the completed disk image in.

Example usage:

If you have a 10.11.0 El Capitan installer available, run this command:

sudo /path/to/create_vmware_osx_install_dmg.sh "/Applications/Install OS X El Capitan.app" /path/to/output_directory

If you had chosen to not create the .ISO file, this should produce a DMG file inside output_directory that’s named something similar to OSX_InstallESD_10.11_15A284.dmg. This DMG will install both OS X 10.11.0 and the first boot package.

If you chose to also create the .ISO, you should have two files inside the chosen directory: OSX_InstallESD_10.11_15A284.dmg and OSX_InstallESD_10.11_15A284.iso

Creating a VM with the customized OS X install .dmg file

1. Launch VMWare Fusion 8.x

2. In VMWare Fusion, select New… under the File menu to set up a new VM

3. In the Select the Installation method window, select Install from disc or image.

4. In the Create a New Virtual Machine window, click on Use another disc or disc image…

5. Select your customized OS X install disk image file and click on the Open button.

6. You’ll be taken back to the Create a New Virtual Machine window. Verify that the disk image file you want is selected, then click the Continue button.

6. In the Choose Operating System window, set OS as appropriate then click the Continue button.

In this example, I’m setting it as follows:

• Operating System: Apple OS X
• Version: OS X 10.11

7. In the Finish window, select Customize Settings if desired.

Otherwise, click Finish.

8. Save the VM file in a convenient location.

The VM is now configured and set to use the customized OS X installer disk image. To install OS X and the packages included with your first boot package, start the VM and then do nothing. The VM should begin automatically installing OS X on the VM’s boot drive, followed by the installation of the first boot package.

If you want to build a customized version of this script, the script and its associated files are available on Github at the following address:

https://github.com/rtrouton/create_os_x_vm_install_dmg

For the past couple of releases, Oracle has used a standard installer package to install Java 8. With the release of Java 8 Update 65 though, Oracle returned to using an application to install Java.

This switch away from using installer packages is a problem for Mac admins who need to deploy Oracle’s Java 8 in their own environment. However, after doing some research, it looks like it is still possible to deploy Oracle’s Java 8 Update 65 using a standard installer package. For more details, see below the jump.

While the Oracle install application is not a standard installer package, it appears that Oracle has stored an installer package for Java 8 within the install application at the following location:

/path/to/install.app/Contents/Resources/JavaAppletPlugin.pkg

Once the JavaAppletPlugin installer package is copied out of the install application, it can be deployed like previous Java updates’ installer packages.

Now that the good news is covered, let’s talk about the install application. Oracle’s Java 8 Update 65 install application has the following behavior:

This application will prompt for admin privileges before fully launching.

Once you provide admin authentication, the application launches.

It will then tell you how many devices run Java while it installs.

Once complete, it’ll tell you what it’s installed.

As best as I can tell, that’s it. Unlike previous incarnations of the install application, the Java 8 Update 65 install application does not appear to try to install any browser toolbars. To verify this behavior, I ran the MacJREInstaller binary which the Oracle Java application is using to actually install the Java browser plug-in.

While I observed that MacJREInstaller continued to check with Oracle and report which country it was being installed in, I did not see anything being downloaded from Oracle. All the functionality to do so is still contained within the MacJREInstaller binary though, so I plan to keep a close eye on this. For those interested, I’ve posted the output below.

Following closely on the heels of Oracle’s release of Java 8 Update 65, Oracle has released Java 8 Update 66. This update is also using Oracle’s install application.

What’s the difference between Update 65 and Update 66? Update 65 is a Critical Patch Update (CPU), which contains both fixes to security vulnerabilities and critical bug fixes. Update 66 is a Patch Set Update (PSU), which means it contains all the fixes in the corresponding CPU, plus additional fixes to non-critical problems. For more details on the differences between CPU and PSU updates, please see the link below:

http://www.oracle.com/technetwork/java/javase/cpu-psu-explained-2331472.html

So the short version is that Update 65 has “critical bug fixes” and Update 66 has “Update 65’s bug fixes, plus more bug fixes.”

You can get Oracle’s Java 8 Update 66 from the link below:

http://www.oracle.com/technetwork/java/javase/downloads/jre8-downloads-2133155.html

For more details on Java 8 Update 66, see below the jump.

While the Oracle install application is not a standard installer package, it appears that Oracle had stored an installer package for Java 8 within the install application at the following location:

/path/to/install.app/Contents/Resources/JavaAppletPlugin.pkg

Once the JavaAppletPlugin installer package is copied out of the install application, it can be deployed like previous Java updates’ installer packages.

Oracle’s Java 8 Update 66 install application has the following behavior:

This application will prompt for admin privileges before fully launching.

Once you provide admin authentication, the application launches.

It will then tell you how many devices run Java while it installs.

Once complete, it’ll tell you what it’s installed.

Unlike previous incarnations of the install application, Java 8 Update 65‘s and Java 8 Update 66‘s install applications do not appear to try to install any browser toolbars. To verify this behavior, I ran the MacJREInstaller binary which the Oracle Java application is using to actually install the Java browser plug-in.

While I observed that Java 8 Update 66’s MacJREInstaller continued to check with Oracle and report which country it was being installed in, I did not see anything being downloaded from Oracle. This behavior matches what I observed with Java 8 Update 65. For those interested, I’ve posted the output below.

If you’re planning to upgrade to OS X El Capitan and you use Outlook 2011 to get email from Microsoft Exchange, you may want to delay upgrading. On El Capitan, connecting to Exchange email servers causes Outlook 2011 to freeze and display a beachball cursor.

https://support.microsoft.com/kb/3098229

The issue appears to only affect Outlook 2011 when configured to access Exchange servers. When set up with only IMAP accounts, Outlook 2011 does not appear to display this behavior.

Microsoft is aware of the issue and has posted a knowledgebase article about it:

https://support.microsoft.com/kb/3098396

As part of the release of OS X El Capitan, Apple has added a new layer named System Integrity Protection (SIP) to its security model. To understand how System Integrity Protection fits in, let’s first take a look at Apple’s security model as it existed as of OS X Yosemite.

Gatekeeper

Gatekeeper is one of the outer lines of defense. It allows users to restrict which sources they can install applications from, with the general idea being that malware will not be from an allowed source.

Sandboxing

OS X also uses sandboxing extensively. A sandbox typically provides a tightly controlled set of resources for programs to run in. Network access, the ability to inspect the host system, or reading from input devices is usually disallowed or heavily restricted.

POSIX permissions

OS X uses the Unix permissions model as defined by POSIX, which governs which users and groups can access which files and directories. If a particular user account requests access to a particular file or directory and does not have the necessary rights, that account is refused access.

Keychains

The innermost layer of defense are keychains. Keychains are very specialized databases which are designed for the storing of secrets, like passwords, private keys, PIN numbers, and then controlling access to those secrets. To help protect these secrets, keychains are encrypted.

There’s an issue with this model though and it’s been there for decades. It pre-exists OS X and even pre-exists Apple as a company. That issue is found in the POSIX permissions layer.

Root

Root is the superuser for a Unix system and the Unix permissions model is designed around the assumption that root has access to everything. Apple has not ignored this issue and has put some controls in place to limit the actual root user. These controls include disabling the root user account, discouraging its use, and providing ways to access elevated or root privileges using other means.

However, the root user account is still present and still can do anything on the system.

System Integrity Protection

To limit what the superuser can do and add another layer to OS X’s security model, Apple has developed SIP and deployed it as part of OS X El Capitan. SIP is designed to limit the power of root and to protect the system even from the superuser. For more details, see below the jump.

SIP is an overall security policy with the goal of preventing system files and processes from being modified by third parties. To achieve this, it has the following concepts:

• File system protection
• Runtime protection
• Kernel extension protection

File system protection

SIP prevents parties other than Apple from adding, deleting or modifying directories and files stored in certain directories:

• /bin
• /sbin
• /usr
• /System

Apple has indicated that the following directories are available for developers to access:

• /usr/local
• /Applications
• /Library
• ~/Library

All directories in /usr except for /usr/local are protected by SIP.

It is possible to add, remove or change SIP-protected files and directories via an installer package which is signed by Apple’s own certificate authority. This allows Apple to make changes to SIP-protected parts of the OS without needing to change the existing SIP protections.

The certificate authority in question is reserved by Apple for their own use; Developer ID-signed installer packages are not able to alter SIP-protected files or directories.

To define which directories are protected, Apple has currently defined two configuration files on the filesystem. The primary one is found at the location below:

/System/Library/Sandbox/rootless.conf

The rootless.conf file lists all the applications and the top-level of directories which SIP is protecting.

Applications

SIP is protecting the core apps which OS X installs into /Applications and /Applications/Utilities.

This means it will no longer be possible to delete the applications which OS X installs, even from the command line when using root privileges.

Directories

SIP is also protecting a number of directories and symlinks outside of /Applications and the top level of those directories are also listed in the rootless.conf file. In addition to protections, Apple has also defined some exceptions to SIP’s protection in the rootless.conf file, and those exceptions are marked with asterixes. These exemptions from SIP’s protection mean that it is possible to add, remove or change files and directories within those locations.

Among those exceptions are the following:

/System/Library/User Template – where OS X stores the template directories it uses when creating home folders for new accounts.
/usr/libexec/cups – where OS X stores printer configuration information

When I’ve spoken with Apple engineers about how this configuration file was updated and if third parties could add their own exceptions to it, it was made clear that Apple considers this file theirs and that any third parties’ changes to it would be overwritten by Apple.

To see which files have been protected by SIP, use the ls command with the capital O flag in Terminal:

ls -O

SIP-protected files will be labeled as restricted.

One important think to know is that even if a symlink is protected by SIP, that does not necessarily mean that the directory they’re linking to is being protected by SIP. At the root level of an OS X El Capitan boot drive, there are several SIP-protected symlinks pointing to directories stored inside the root-level directory named private.

However, when the contents of the directory named private are examined, the directories which those symlinks point to are not protected by SIP and both they and their contents can be moved, edited or changed by processes using root privileges.

In addition to the list of SIP exceptions which Apple has set in rootless.conf, there is a second list of SIP exceptions. This list includes a number of directories and application names for third-party products. Similar to rootless.conf, this exclusion list is Apple’s and any third parties’ changes to it will be overwritten by Apple.

/System/Library/Sandbox/Compatibility.bundle/Contents/Resources/paths

Runtime protection

SIP’s protections are not limited to protecting the system from filesystem changes. There are also system calls which are now restricted in their functionality.

• task_for_pid() / processor_set_tasks() fail with EPERM
• Mach special ports are reset on exec(2)
• dyld environment variables are ignored
• DTrace probes unavailable

However, SIP does not block inspection by the developer of their own applications while they’re being developed. Xcode’s tools will continue to allow apps to be inspected and debugged during the development process.

For more details on this, I recommend taking a look at Apple’s developer documentation for SIP.

Kernel extension protection

SIP blocks installation of unsigned kernel extensions. In order to install a kernel extension on OS X El Capitan with SIP enabled, a kernel extension must:

1. Be signed with a Developer ID for Signing Kexts certificate
2. Install into /Library/Extensions

If installing an unsigned kernel extension, SIP will need to be disabled first.

Managing SIP

To help ensure that third parties will not be able to disable these protections, SIP’s configuration is stored in NVRAM rather than in the file system itself and is only configurable if the Mac is booted into one of two environments:

• The OS X Installer environment
• The OS X Recovery environment

Note: The OS X Installer and OS X Recovery environments are in fact the same environment from OS X’s perspective, with the main difference being that the OS X Installer environment contains a copy of the installation files for OS X and the Recovery environment does not.

Because SIP’s configuration is stored in NVRAM, SIP’s protection settings will apply to the entire machine and will persist even if the OS is reinstalled.

SIP can be managed to the extent of turning it on, turning it off, adding and removing IP addresses into a NetBoot whitelist and reporting on whether SIP is enabled or disabled. All changes to SIP’s configuration also require a reboot before they take effect.

The tool used to manage SIP is /usr/bin/csrutil. csrutil is able to work with SIP because it has a unique application entitlement assigned to it by Apple. This entitlement is viewable using the codesign command shown below:

codesign -d --entitlements - /usr/bin/csrutil

When you run csrutil without any associated commands, it will pull up the help page.

When booted from Recovery, the command used to enable SIP is csrutil enable:

csrutil enable

When booted from Recovery, the command used to turn SIP off is csrutil disable:

csrutil disable

When booted from Recovery, the command used to reset SIP’s configuration is csrutil clear:

csrutil clear

When csrutil clear is run, SIP goes back to its factory-default settings. That means SIP is enabled if it was disabled previously and any custom configuration is cleared out.

SIP and NetBoot

One of the custom configuration options available in SIP is the ability to set a whitelist for approved NetBoot servers. This whitelist is needed because the bless command in El Capitan is restricted by SIP from writing to NVRAM. This affects bless‘s ability to set Macs to boot from NetBoot sets because it needs to write that information to NVRAM.

This whitelist defines by IP address which NetBoot servers are trusted in your environment. Once those IP addresses are part of the whitelist, the bless command can set a Mac to NetBoot from a NetBoot set on a trusted NetBoot server. For more information about whether or not you need to whitelist your NetBoot server(s), please see the link below:

https://derflounder.wordpress.com/2015/09/05/netbooting-and-system-integrity-protection/

To help folks who need to use bless to set a NetBoot set as a startup drive, the csrutil tool includes functionality to add NetBoot servers to the whitelist. While booted from Recovery, use csrutil netboot add followed by an IP address to set the IP as being that of a NetBoot server approved for use by the bless command:

csrutil netboot add ip.address.here

While booted from Recovery, you can also remove NetBoot servers from the whitelist. To do this, use csrutil netboot remove followed by the IP address that you want to remove from the whitelist.

csrutil netboot remove ip.address.here

To see which NetBoot servers have been added to the whitelist, run csrutil netboot list.

csrutil netboot list

Running csrutil outside Recovery

If you try to run the csrutil enable and csrutil disable commands while booted from a regular boot drive, you will receive a message that these commands need to be run from Recovery. The current SIP configuration will remain unchanged.

Likewise, if you try to run the csrutil netboot add and csrutil netboot remove commands while booted from a regular boot drive, you will receive the message that csrutil was unable to save the configuration and the status of the NetBoot whitelist will remain unchanged.

What can be run while booted from a regular boot drive is csrutil’s reporting functions. For example, to learn if SIP is enabled or disabled, run csrutil status.

csrutil status

This command can be run without root privileges and will tell you if SIP is on or off.

If SIP is off, you may receive a confusing message which indicates that SIP is enabled, followed by a list of individual SIP functions which are disabled. If all functions listed are showing as being disabled, SIP is actually completely disabled; it’s just confusingly worded.

I actually have a bug report on this message. For those who wish to dupe it, it is bug ID 22361698 and is cross-posted to Open Radar here:

https://openradar.appspot.com/radar?id=4932475130216448

Likewise, you can run csrutil netboot list and it will report on which IPs have been set as allowed NetBoot sources when using the bless command.

Other custom SIP configuration options

It is also possible to enable SIP protections and selectively disable aspects of it, by adding one or more flags to the csrutil enable command. All require being booted from Recovery in order to set them:

Enable SIP and allow installation of unsigned kernel extensions

csrutil enable --without kext

When this option is enabled, running csrutil status should produce output similar to this.

Enable SIP and disable filesystem protections

csrutil enable --without fs

When this option is enabled, running csrutil status should produce output similar to this.

Enable SIP and disable debugging restrictions

csrutil enable --without debug

When this option is enabled, running csrutil status should produce output similar to this.

Enable SIP and disable DTrace restrictions

csrutil enable --without dtrace

When this option is enabled, running csrutil status should produce output similar to this.

Enable SIP and disable restrictions on writing to NVRAM

csrutil enable --without nvram

When this option is enabled, running csrutil status should produce output similar to this.

Conclusion

SIP is a big change, but I think it should also be considered a work in progress. I’m expecting to see additional changes to SIP’s functionality in both El Capitan and future releases of OS X, as Apple sees how SIP works in the real world.

One of the hidden features of OS X El Capitan is the ability to enable Internet Sharing to provide only IPv6 addresses. This feature was added to El Capitan to help developers ensure their apps are ready to work with IPv6. It uses NAT64, which facilitates communication between IPv6 and IPv4 hosts by using a form of NAT.

For those interested in having the ability to set up an IPv6-only network, see below the jump for the procedure.

Pre-requisite:

A Mac running OS X 10.11.x

1. Open System Preferences

2. Option-click on the Sharing preference pane

3. A Create NAT64 Network checkbox will appear (this may also be labeled Create IPv6 Only Network.)

4. Check Create NAT64 Network.

5. Select the interface to share out over

6. Check the Internet Sharing checkbox

7. When prompted, click the Start button

8. An IPv6-only network should now be available.

One interesting part of Apple’s developer documentation for System Integrity Protection (SIP) is the note shown below, indicating that it’s possible to configure SIP for environments that can’t access Recovery.

When I followed up with Apple about this, I was told that this meant I could configure it using NetBoot, using a NetBoot set that included the needed Recovery environment.

The example used was leveraging a new option in System Image Utility to create a package-only installation NetBoot set.

This new type of NetBoot set is is designed to install only scripts, configuration profiles and packages as opposed to installing an OS. For more details, see below the jump.

To test this, I wrote a script that uses csrutil netboot add to add two IP addresses to the NetBoot whitelist.

Once I had my script written, I built a package-only NetBoot set using System Image Utility and added the script to it.

Once completed, I booted a VM running OS X El Capitan from the NetBoot set to verify that the process works.

To demonstrate how the process looks, I’ve made a video showing the following process:

1. Running csrutil status and csrutil netboot list to show that the Mac has SIP enabled, but no entries in the NetBoot whitelist.
2. NetBooting the VM from the packages-only NetBoot set
3. The NetBoot set running the script and rebooting
4. Running csrutil status to show that the Mac has SIP enabled and now also has the two IP addresses added to the NetBoot whitelist.

Note: The video has been edited to artificially reduce the amount of time it took to NetBoot and restart.

As my colleague @quovadimus82 has previously documented, OS X El Capitan includes a new option for showing and hiding the menubar.

This option is available in System Preferences, in the General preferences.

It is also possible to use the defaults command to set the menubar’s behavior. Here’s how you can set the menubar to be hidden and unhidden using defaults:

To hide:

defaults write NSGlobalDomain _HIHideMenuBar -bool true

To show:

defaults write NSGlobalDomain _HIHideMenuBar -bool false

Once run, logout and log back in to see the change in behavior. Alternatively, you can run the following command as the logged-in user to restart Finder and show the changes:

killall Finder

For those who wanted a copy of my security talk at JAMF Nation User Conference 2015, here are links to the slides in PDF and Keynote format.

PDF – http://tinyurl.com/JNUC2015SecurityPDF

Keynote – http://tinyurl.com/JNUC2015SecurityKeynote

@clburlison has discovered that you can take screenshots of the OS X login window on OS X El Capitan using OS X’s keyboard shortcuts for making screenshots.

This appears to be a new feature of El Capitan, as I was unable to reproduce this behavior on OS X Yosemite.

In my testing, I’ve verified that using the following commands work:

• Take a screenshot of the entire login window: Command+Shift+3
• Take a screenshot of a user-selected area of the login window: Command+Shift+4

The screenshot file(s) will then appear on the desktop of the next user to log in.

To distinguish these login window screenshots from screenshots taken while logged in, the login window screenshots’ filenames begin with LW.

I’ve updated the create_vmware_osx_install_dmg.sh script that I had previously posted about here. The script now includes support for El Capitan, so the script can now be run on 10.7 – 10.11 to create custom OS X 10.7.x, 10.8.x, 10.9.x, 10.10.x and 10.11.x installers for VMware Fusion and VMware ESXi. See below the jump for the details.

Downloading the script and support files

Download a .zip archive containing all needed files from my GitHub repo. This will give you both the create_vmware_osx_install_dmg script and a directory named support which contains files that the script will be copying into the completed disk image.

Both the create_vmware_osx_install_dmg script and the support directory must be stored in the same directory in order for the script to work properly.

Once you have the .zip archive download and uncompressed, go into the support directory and unzip the First_Boot_Package_Install.zip file. First Boot Package Install.pkg is used by the script so it’ll need to be unzipped and prepared before running the script.

Note: The First Boot Package Install.pkg included with this script will automatically install all available Apple software updates following the OS installation, but provide no other customization for the VM.

Creating a customized first boot package

If you want to have a first boot package that installs other packages at first boot, I’ve written a tool named First Boot Package Install Generator.app that will generate a first boot package that works with this script.

NOTE: The customized OS X installer will have an upper limit of 350 MBs of available space for added packages. This is sufficient space for basic configuration, payload-free or bootstrapping packages, but it’s not a good idea to add Microsoft Office or similar large installers to this installer.

For details on how to use First Boot Package Install Generator.app to generate your first boot package, please see this post:

https://derflounder.wordpress.com/2014/10/19/first-boot-package-install-generator-app/

When using a first boot package with this script, the script has the following hard-coded requirements:

1. That the first boot package is named First Boot Package Install.pkg
2. That the first boot package is stored in the support directory.

Running the script to create a customized OS X install .dmg file

Once you have the first boot package available and configured to your preferences, run the create_vmware_osx_install_dmg script with two arguments:

1. The path to an Install OS X.app or the InstallESD.dmg contained within.
2. A directory to store the completed disk image in.

Example usage:

If you have a 10.11.0 El Capitan installer available, run this command:

sudo /path/to/create_vmware_osx_install_dmg.sh "/Applications/Install OS X El Capitan.app" /path/to/output_directory

If you had chosen to not create the .ISO file, this should produce a DMG file inside output_directory that’s named something similar to OSX_InstallESD_10.11_15A284.dmg. This DMG will install both OS X 10.11.0 and the first boot package.

If you chose to also create the .ISO, you should have two files inside the chosen directory: OSX_InstallESD_10.11_15A284.dmg and OSX_InstallESD_10.11_15A284.iso

Creating a VM with the customized OS X install .dmg file

1. Launch VMWare Fusion 8.x

2. In VMWare Fusion, select New… under the File menu to set up a new VM

3. In the Select the Installation method window, select Install from disc or image.

4. In the Create a New Virtual Machine window, click on Use another disc or disc image…

5. Select your customized OS X install disk image file and click on the Open button.

6. You’ll be taken back to the Create a New Virtual Machine window. Verify that the disk image file you want is selected, then click the Continue button.

6. In the Choose Operating System window, set OS as appropriate then click the Continue button.

In this example, I’m setting it as follows:

• Operating System: Apple OS X
• Version: OS X 10.11

7. In the Finish window, select Customize Settings if desired.

Otherwise, click Finish.

8. Save the VM file in a convenient location.

The VM is now configured and set to use the customized OS X installer disk image. To install OS X and the packages included with your first boot package, start the VM and then do nothing. The VM should begin automatically installing OS X on the VM’s boot drive, followed by the installation of the first boot package.

If you want to build a customized version of this script, the script and its associated files are available on Github at the following address:

https://github.com/rtrouton/create_os_x_vm_install_dmg

For the past couple of releases, Oracle has used a standard installer package to install Java 8. With the release of Java 8 Update 65 though, Oracle returned to using an application to install Java.

This switch away from using installer packages is a problem for Mac admins who need to deploy Oracle’s Java 8 in their own environment. However, after doing some research, it looks like it is still possible to deploy Oracle’s Java 8 Update 65 using a standard installer package. For more details, see below the jump.

While the Oracle install application is not a standard installer package, it appears that Oracle has stored an installer package for Java 8 within the install application at the following location:

/path/to/install.app/Contents/Resources/JavaAppletPlugin.pkg

Once the JavaAppletPlugin installer package is copied out of the install application, it can be deployed like previous Java updates’ installer packages.

Now that the good news is covered, let’s talk about the install application. Oracle’s Java 8 Update 65 install application has the following behavior:

This application will prompt for admin privileges before fully launching.

Once you provide admin authentication, the application launches.

It will then tell you how many devices run Java while it installs.

Once complete, it’ll tell you what it’s installed.

As best as I can tell, that’s it. Unlike previous incarnations of the install application, the Java 8 Update 65 install application does not appear to try to install any browser toolbars. To verify this behavior, I ran the MacJREInstaller binary which the Oracle Java application is using to actually install the Java browser plug-in.

While I observed that MacJREInstaller continued to check with Oracle and report which country it was being installed in, I did not see anything being downloaded from Oracle. All the functionality to do so is still contained within the MacJREInstaller binary though, so I plan to keep a close eye on this. For those interested, I’ve posted the output below.

Following closely on the heels of Oracle’s release of Java 8 Update 65, Oracle has released Java 8 Update 66. This update is also using Oracle’s install application.

What’s the difference between Update 65 and Update 66? Update 65 is a Critical Patch Update (CPU), which contains both fixes to security vulnerabilities and critical bug fixes. Update 66 is a Patch Set Update (PSU), which means it contains all the fixes in the corresponding CPU, plus additional fixes to non-critical problems. For more details on the differences between CPU and PSU updates, please see the link below:

http://www.oracle.com/technetwork/java/javase/cpu-psu-explained-2331472.html

So the short version is that Update 65 has “critical bug fixes” and Update 66 has “Update 65’s bug fixes, plus more bug fixes.”

You can get Oracle’s Java 8 Update 66 from the link below:

http://www.oracle.com/technetwork/java/javase/downloads/jre8-downloads-2133155.html

For more details on Java 8 Update 66, see below the jump.

While the Oracle install application is not a standard installer package, it appears that Oracle had stored an installer package for Java 8 within the install application at the following location:

/path/to/install.app/Contents/Resources/JavaAppletPlugin.pkg

Once the JavaAppletPlugin installer package is copied out of the install application, it can be deployed like previous Java updates’ installer packages.

Oracle’s Java 8 Update 66 install application has the following behavior:

This application will prompt for admin privileges before fully launching.

Once you provide admin authentication, the application launches.

It will then tell you how many devices run Java while it installs.

Once complete, it’ll tell you what it’s installed.

Unlike previous incarnations of the install application, Java 8 Update 65‘s and Java 8 Update 66‘s install applications do not appear to try to install any browser toolbars. To verify this behavior, I ran the MacJREInstaller binary which the Oracle Java application is using to actually install the Java browser plug-in.

While I observed that Java 8 Update 66’s MacJREInstaller continued to check with Oracle and report which country it was being installed in, I did not see anything being downloaded from Oracle. This behavior matches what I observed with Java 8 Update 65. For those interested, I’ve posted the output below.

As part of the release of OS X El Capitan, Apple has added a new layer named System Integrity Protection (SIP) to its security model. To understand how System Integrity Protection fits in, let’s first take a look at Apple’s security model as it existed as of OS X Yosemite.

Gatekeeper

Gatekeeper is one of the outer lines of defense. It allows users to restrict which sources they can install applications from, with the general idea being that malware will not be from an allowed source.

Sandboxing

OS X also uses sandboxing extensively. A sandbox typically provides a tightly controlled set of resources for programs to run in. Network access, the ability to inspect the host system, or reading from input devices is usually disallowed or heavily restricted.

POSIX permissions

OS X uses the Unix permissions model as defined by POSIX, which governs which users and groups can access which files and directories. If a particular user account requests access to a particular file or directory and does not have the necessary rights, that account is refused access.

Keychains

The innermost layer of defense are keychains. Keychains are very specialized databases which are designed for the storing of secrets, like passwords, private keys, PIN numbers, and then controlling access to those secrets. To help protect these secrets, keychains are encrypted.

There’s an issue with this model though and it’s been there for decades. It pre-exists OS X and even pre-exists Apple as a company. That issue is found in the POSIX permissions layer.

Root

Root is the superuser for a Unix system and the Unix permissions model is designed around the assumption that root has access to everything. Apple has not ignored this issue and has put some controls in place to limit the actual root user. These controls include disabling the root user account, discouraging its use, and providing ways to access elevated or root privileges using other means.

However, the root user account is still present and still can do anything on the system.

System Integrity Protection

To limit what the superuser can do and add another layer to OS X’s security model, Apple has developed SIP and deployed it as part of OS X El Capitan. SIP is designed to limit the power of root and to protect the system even from the superuser. For more details, see below the jump.

SIP is an overall security policy with the goal of preventing system files and processes from being modified by third parties. To achieve this, it has the following concepts:

• File system protection
• Runtime protection
• Kernel extension protection

File system protection

SIP prevents parties other than Apple from adding, deleting or modifying directories and files stored in certain directories:

• /bin
• /sbin
• /usr
• /System

Apple has indicated that the following directories are available for developers to access:

• /usr/local
• /Applications
• /Library
• ~/Library

All directories in /usr except for /usr/local are protected by SIP.

It is possible to add, remove or change SIP-protected files and directories via an installer package which is signed by Apple’s own certificate authority. This allows Apple to make changes to SIP-protected parts of the OS without needing to change the existing SIP protections.

The certificate authority in question is reserved by Apple for their own use; Developer ID-signed installer packages are not able to alter SIP-protected files or directories.

To define which directories are protected, Apple has currently defined two configuration files on the filesystem. The primary one is found at the location below:

/System/Library/Sandbox/rootless.conf

The rootless.conf file lists all the applications and the top-level of directories which SIP is protecting.

Applications

SIP is protecting the core apps which OS X installs into /Applications and /Applications/Utilities.

This means it will no longer be possible to delete the applications which OS X installs, even from the command line when using root privileges.

Directories

SIP is also protecting a number of directories and symlinks outside of /Applications and the top level of those directories are also listed in the rootless.conf file. In addition to protections, Apple has also defined some exceptions to SIP’s protection in the rootless.conf file, and those exceptions are marked with asterixes. These exemptions from SIP’s protection mean that it is possible to add, remove or change files and directories within those locations.

Among those exceptions are the following:

/System/Library/User Template – where OS X stores the template directories it uses when creating home folders for new accounts.
/usr/libexec/cups – where OS X stores printer configuration information

When I’ve spoken with Apple engineers about how this configuration file was updated and if third parties could add their own exceptions to it, it was made clear that Apple considers this file theirs and that any third parties’ changes to it would be overwritten by Apple.

To see which files have been protected by SIP, use the ls command with the capital O flag in Terminal:

ls -O

SIP-protected files will be labeled as restricted.

One important think to know is that even if a symlink is protected by SIP, that does not necessarily mean that the directory they’re linking to is being protected by SIP. At the root level of an OS X El Capitan boot drive, there are several SIP-protected symlinks pointing to directories stored inside the root-level directory named private.

However, when the contents of the directory named private are examined, the directories which those symlinks point to are not protected by SIP and both they and their contents can be moved, edited or changed by processes using root privileges.

In addition to the list of SIP exceptions which Apple has set in rootless.conf, there is a second list of SIP exceptions. This list includes a number of directories and application names for third-party products. Similar to rootless.conf, this exclusion list is Apple’s and any third parties’ changes to it will be overwritten by Apple.

/System/Library/Sandbox/Compatibility.bundle/Contents/Resources/paths

Runtime protection

SIP’s protections are not limited to protecting the system from filesystem changes. There are also system calls which are now restricted in their functionality.

• task_for_pid() / processor_set_tasks() fail with EPERM
• Mach special ports are reset on exec(2)
• dyld environment variables are ignored
• DTrace probes unavailable

However, SIP does not block inspection by the developer of their own applications while they’re being developed. Xcode’s tools will continue to allow apps to be inspected and debugged during the development process.

For more details on this, I recommend taking a look at Apple’s developer documentation for SIP.

Kernel extension protection

SIP blocks installation of unsigned kernel extensions. In order to install a kernel extension on OS X El Capitan with SIP enabled, a kernel extension must:

1. Be signed with a Developer ID for Signing Kexts certificate
2. Install into /Library/Extensions

If installing an unsigned kernel extension, SIP will need to be disabled first.

Managing SIP

To help ensure that third parties will not be able to disable these protections, SIP’s configuration is stored in NVRAM rather than in the file system itself and is only configurable if the Mac is booted into one of two environments:

• The OS X Installer environment
• The OS X Recovery environment

Note: The OS X Installer and OS X Recovery environments are in fact the same environment from OS X’s perspective, with the main difference being that the OS X Installer environment contains a copy of the installation files for OS X and the Recovery environment does not.

Because SIP’s configuration is stored in NVRAM, SIP’s protection settings will apply to the entire machine and will persist even if the OS is reinstalled.

SIP can be managed to the extent of turning it on, turning it off, adding and removing IP addresses into a NetBoot whitelist and reporting on whether SIP is enabled or disabled. All changes to SIP’s configuration also require a reboot before they take effect.

The tool used to manage SIP is /usr/bin/csrutil. csrutil is able to work with SIP because it has a unique application entitlement assigned to it by Apple. This entitlement is viewable using the codesign command shown below:

codesign -d --entitlements - /usr/bin/csrutil

When you run csrutil without any associated commands, it will pull up the help page.

When booted from Recovery, the command used to enable SIP is csrutil enable:

csrutil enable

When booted from Recovery, the command used to turn SIP off is csrutil disable:

csrutil disable

When booted from Recovery, the command used to reset SIP’s configuration is csrutil clear:

csrutil clear

When csrutil clear is run, SIP goes back to its factory-default settings. That means SIP is enabled if it was disabled previously and any custom configuration is cleared out.

SIP and NetBoot

One of the custom configuration options available in SIP is the ability to set a whitelist for approved NetBoot servers. This whitelist is needed because the bless command in El Capitan is restricted by SIP from writing to NVRAM. This affects bless‘s ability to set Macs to boot from NetBoot sets because it needs to write that information to NVRAM.

This whitelist defines by IP address which NetBoot servers are trusted in your environment. Once those IP addresses are part of the whitelist, the bless command can set a Mac to NetBoot from a NetBoot set on a trusted NetBoot server. For more information about whether or not you need to whitelist your NetBoot server(s), please see the link below:

https://derflounder.wordpress.com/2015/09/05/netbooting-and-system-integrity-protection/

To help folks who need to use bless to set a NetBoot set as a startup drive, the csrutil tool includes functionality to add NetBoot servers to the whitelist. While booted from Recovery, use csrutil netboot add followed by an IP address to set the IP as being that of a NetBoot server approved for use by the bless command:

csrutil netboot add ip.address.here

While booted from Recovery, you can also remove NetBoot servers from the whitelist. To do this, use csrutil netboot remove followed by the IP address that you want to remove from the whitelist.

csrutil netboot remove ip.address.here

To see which NetBoot servers have been added to the whitelist, run csrutil netboot list.

csrutil netboot list

Running csrutil outside Recovery

If you try to run the csrutil enable and csrutil disable commands while booted from a regular boot drive, you will receive a message that these commands need to be run from Recovery. The current SIP configuration will remain unchanged.

Likewise, if you try to run the csrutil netboot add and csrutil netboot remove commands while booted from a regular boot drive, you will receive the message that csrutil was unable to save the configuration and the status of the NetBoot whitelist will remain unchanged.

What can be run while booted from a regular boot drive is csrutil’s reporting functions. For example, to learn if SIP is enabled or disabled, run csrutil status.

csrutil status

This command can be run without root privileges and will tell you if SIP is on or off.

If SIP is off, you may receive a confusing message which indicates that SIP is enabled, followed by a list of individual SIP functions which are disabled. If all functions listed are showing as being disabled, SIP is actually completely disabled; it’s just confusingly worded.

I actually have a bug report on this message. For those who wish to dupe it, it is bug ID 22361698 and is cross-posted to Open Radar here:

https://openradar.appspot.com/radar?id=4932475130216448

Likewise, you can run csrutil netboot list and it will report on which IPs have been set as allowed NetBoot sources when using the bless command.

Other custom SIP configuration options

It is also possible to enable SIP protections and selectively disable aspects of it, by adding one or more flags to the csrutil enable command. All require being booted from Recovery in order to set them:

Enable SIP and allow installation of unsigned kernel extensions

csrutil enable --without kext

When this option is enabled, running csrutil status should produce output similar to this.

Enable SIP and disable filesystem protections

csrutil enable --without fs

When this option is enabled, running csrutil status should produce output similar to this.

Enable SIP and disable debugging restrictions

csrutil enable --without debug

When this option is enabled, running csrutil status should produce output similar to this.

Enable SIP and disable DTrace restrictions

csrutil enable --without dtrace

When this option is enabled, running csrutil status should produce output similar to this.

Enable SIP and disable restrictions on writing to NVRAM

csrutil enable --without nvram

When this option is enabled, running csrutil status should produce output similar to this.

Conclusion

SIP is a big change, but I think it should also be considered a work in progress. I’m expecting to see additional changes to SIP’s functionality in both El Capitan and future releases of OS X, as Apple sees how SIP works in the real world.

One of the hidden features of OS X El Capitan is the ability to enable Internet Sharing to provide only IPv6 addresses. This feature was added to El Capitan to help developers ensure their apps are ready to work with IPv6. It uses NAT64, which facilitates communication between IPv6 and IPv4 hosts by using a form of NAT.

For those interested in having the ability to set up an IPv6-only network, see below the jump for the procedure.

Pre-requisite:

A Mac running OS X 10.11.x

1. Open System Preferences

2. Option-click on the Sharing preference pane

3. A Create NAT64 Network checkbox will appear (this may also be labeled Create IPv6 Only Network.)

4. Check Create NAT64 Network.

5. Select the interface to share out over

6. Check the Internet Sharing checkbox

7. When prompted, click the Start button

8. An IPv6-only network should now be available.

One interesting part of Apple’s developer documentation for System Integrity Protection (SIP) is the note shown below, indicating that it’s possible to configure SIP for environments that can’t access Recovery.

When I followed up with Apple about this, I was told that this meant I could configure it using NetBoot, using a NetBoot set that included the needed Recovery environment.

The example used was leveraging a new option in System Image Utility to create a package-only installation NetBoot set.

This new type of NetBoot set is is designed to install only scripts, configuration profiles and packages as opposed to installing an OS. For more details, see below the jump.

To test this, I wrote a script that uses csrutil netboot add to add two IP addresses to the NetBoot whitelist.

Once I had my script written, I built a package-only NetBoot set using System Image Utility and added the script to it.

Once completed, I booted a VM running OS X El Capitan from the NetBoot set to verify that the process works.

To demonstrate how the process looks, I’ve made a video showing the following process:

1. Running csrutil status and csrutil netboot list to show that the Mac has SIP enabled, but no entries in the NetBoot whitelist.
2. NetBooting the VM from the packages-only NetBoot set
3. The NetBoot set running the script and rebooting
4. Running csrutil status to show that the Mac has SIP enabled and now also has the two IP addresses added to the NetBoot whitelist.

Note: The video has been edited to artificially reduce the amount of time it took to NetBoot and restart.

As my colleague @quovadimus82 has previously documented, OS X El Capitan includes a new option for showing and hiding the menubar.

This option is available in System Preferences, in the General preferences.

It is also possible to use the defaults command to set the menubar’s behavior. Here’s how you can set the menubar to be hidden and unhidden using defaults:

To hide:

defaults write NSGlobalDomain _HIHideMenuBar -bool true

To show:

defaults write NSGlobalDomain _HIHideMenuBar -bool false

Once run, logout and log back in to see the change in behavior. Alternatively, you can run the following command as the logged-in user to restart Finder and show the changes:

killall Finder