FileVault recovery key redirection profile changes in macOS High Sierra

January 15, 2018 2 comments

For macOS Sierra and earlier, Apple had a dedicated FileVault Recovery Key Redirection profile payload for FileVault recovery key redirection. This profile was designed to work with a mobile device management (MDM) server, to allow the MDM server to act as a recovery key escrow service and store FileVault personal recovery keys.

Screen Shot 2018 01 15 at 12 40 23 PM

Note: Jamf Pro will be used as the example MDM server in this post. However, similar functionality is available in other MDM services.

On macOS High Sierra, this FileVault Recovery Key Redirection profile payload no longer works. In its place, Apple has added new Enable Escrow Personal Recovery Key settings to the FileVault section of the existing Security profile payload.

Screen Shot 2018 01 15 at 12 44 56 PM

Adding the recovery key redirection to the Security payload may cause issues in some environments, as the Security profile payload has other settings which those environments may prefer to manage separately, or not manage at all.

For those who prefer to manage FileVault recovery key redirection separately from the other settings managed by the Security payload, it is possible to create a profile (with some manual editing) which only manages FileVault recovery key redirection. For more details, see below the jump.

Read more…

Secure Enclave, Mac SSD hardware encryption and the future of FileVault

January 8, 2018 3 comments

The iMac Pro introduced a number of new features, but one that may have been little noticed is the introduction of hardware encryption for the iMac Pro’s SSD storage. Apple references the hardware encryption on the iMac Pro page this way:

T2 also makes iMac Pro even more secure, thanks to a Secure Enclave coprocessor that provides the foundation for new encrypted storage and secure boot capabilities. The data on your SSD is encrypted using dedicated AES hardware with no effect on the SSD’s performance, while keeping the Intel Xeon processor free for your compute tasks.

Screen Shot 2018 01 07 at 9 32 21 PM

This hardware encryption means that, even if FileVault is not enabled, the data stored on the iMac Pro’s SSD storage is encrypted. What’s more, the key to unlock the encryption is stored in the iMac Pro’s Secure Enclave and never leaves the machine. Physically remove the SSD storage from the iMac Pro and you won’t be able to access any data stored on the SSD, even if you have an otherwise identical iMac Pro available.

For those with knowledge of how Apple protects data stored on iOS devices, this should sound familiar. The main difference between the iOS and macOS implementation at this point appears to be that macOS does not have the equivalent passcode lock screen.

Iphone7 ios11 passcode lock screen

Instead, the needed encryption key to unlock the hardware encryption is automatically provided by the Secure Enclave when the iMac Pro boots. This behavior is just like that seen on an iOS device where a passcode has not been enabled.

This is referenced when you run the following command on an iMac Pro:

diskutil apfs list

On an iMac Pro where FileVault is not enabled, FileVault is shown with the following status:

FileVault: No (Encrypted at rest)

Screen Shot 2018 01 07 at 9 28 23 PM

This recognizes that encryption is available, but that the encryption only provides protection when the data is at rest. “Data at rest” in this context should be understood to mean when the Secure Enclave has not provided the needed encryption unlock key, which would be the case in either of the following scenarios:

  1. The iMac Pro is off.
  2. The SSD storage has been removed from the iMac Pro.

For more, please see below the jump.

Read more…

Setting your Mac to receive macOS beta updates using seedutil

January 6, 2018 Leave a comment

As part of a discussion of how to build test VMs, a colleague mentioned how they were using the seedutil tool to help configure Macs to access Apple’s beta updates. I hadn’t run across this tool before, so I decided to do some research and see if I could make it work for my own testing needs. For more details, see below the jump.

Read more…

Decrypting an APFS encrypted volume using diskutil on macOS 10.13.2

December 31, 2017 1 comment

Apple has made changes as of macOS 10.13.2 to the way you can turn off APFS encryption when using the diskutil apfs decryptVolume command.

On macOS 10.13.0 and 10.13.1, an APFS encrypted volume could be decrypted using the following procedure:

  1. Identify the relevant encrypted APFS volume
  2. Unlock the encrypted APFS volume
  3. Decrypt the encrypted APFS volume

Once the drive has been unlocked, you could then decrypt the APFS volume using the command shown below:

diskutil apfs decryptVolume /dev/apfs_volume_id_here

As long as you were using root or admin privileges to run the command, no additional authentication was required to decrypt an unlocked encrypted volume.

Screen Shot 2017 11 03 at 11 02 23 PM

However, the diskutil apfs decryptVolume command has been updated on macOS 10.13.2 to require additional authentication:

In order to decrypt using a user account’s password or personal recovery key (PRK), it is necessary to specify the following:

  1. The relevant user UUID
  2. The relevant account password or the PRK.

Note: As of macOS 10.13.2, it is not possible to decrypt an encrypted APFS volume using an institutional recovery key (IRK). You can unlock an encrypted APFS volume using an IRK, but diskutil apfs decryptVolume does not include functionality for using an IRK to authenticate the decryption of an encrypted APFS volume.

For more details, please see below the jump.

Read more…

Creating local user accounts with pycreateuserpkg

December 24, 2017 1 comment

As part of setting up new Macs, you may want to add one or more local user accounts with a pre-determined password to those Macs. The reasons for this may include the following:

  • Setting up a local administrator account
  • Setting up a “loaner” user account for a pool of loaner laptops
  • Setting up a local user account that automatically logs at startup for a library kiosk
  • Setting up a generic “student” account for use in a school’s computer lab

Previously, it was possible to use the venerable CreateUserPkg utility to accomplish this goal, but the password scheme used by CreateUserPkg stopped working on macOS High Sierra. An alternative tool which works on macOS High Sierra is pycreateuserpkg, a Python script written by Greg Neagle which generates packages that create local user accounts when installed. For more information, see below the jump.

Read more…

Security Update 2017-001 being pushed to both macOS 10.13.0 and 10.13.1

November 30, 2017 4 comments

To fix the vulnerability popularly referred to as #IAMROOT , Apple has begun pushing Security Update 2017-001 to Macs running the following OS versions:

  • macOS 10.13.0
  • macOS 10.13.1

This update is being deployed using the same automated installation mechanism that Apple previously used to deploy OS X NTP Security Update 1.0 back in 2014, where Security Update 2017-001 is being silently downloaded and installed on vulnerable Macs.

Screen Shot 2017 11 30 at 2 08 59 PM

For more details, please see below the jump.

Read more…

Categories: Mac administration, macOS

Blocking logins to the root account on macOS High Sierra

November 28, 2017 7 comments

A security vulnerability was discovered in macOS High Sierra today, where you could enable and log into the root account without providing a password.



Update 11-29-2017: Apple has released Security Update 2017-001 to fix this issue. Please install this update as soon as possible.




Update 11-30-2017: Apple is now automatically installing Security Update 2017-001 on vulnerable Macs.



To address this this issue until Apple releases an update to fix it, there’s two steps you can take which will block logins to the root account:

  1. Set a password for the root account on your Mac
  2. Change the root’s account’s login shell to /usr/bin/false

When you set the root account’s login shell to /usr/bin/false, the shell is changed to point to a command that does nothing except return a status code which reports an error. The login process will interpret that error status code as being a failed login, so it will stop the login process at that point and prompt for the password again.

Since the login process will always receive the error code from the false command, the login process will never succeed. For more details, see below the jump.

Read more…

Categories: Mac administration, macOS
%d bloggers like this: