Back in OS X 10.8.x, one of the newly-created fdesetup tool’s functions was to enable users for FileVault 2. To do so, you needed to provide both the username and password of either a previously enabled account or an admin account, as well as the password of the account you want to add.
One interesting twist was that the admin user in question did not themselves need to be enabled for FileVault 2. In my testing on 10.8.x, I found that an admin user could authorize the enabling of other accounts even if the admin account wasn’t enabled. An admin account could also enable itself using this process, by being both the authorizing admin account and the account being enabled.
In Mavericks and later, this behavior changed. If you’re using Mavericks or Yosemite, the fdesetup tool included with those operating systems now prevents non-enabled admin users from enabling other non-enabled users.
That seemed to close the book on non-enabled admin accounts being able to enable users for FileVault 2, until Google’s Macintosh Operations Team posted a script that they said would make a Mac unbootable.
As part of the discussion about that script, something really interesting was discovered. For more details, see below the jump.
At the time of posting, the script was designed to do the following:
If the Mac’s boot drive was FileVault 2-encrypted, the script:
- Adds a new user called fde_locked_user with a random password.
- Adds this user to the list of users who can unlock the disk.
- Removes all other users.
- Shuts down the machine.
If the Mac’s boot drive was not FileVault 2-encrypted, the script:
- Renames /sbin/launchd to /sbin/launchd_disabled
- Shuts down the machine
Unfortunately, as it was set up, the “If the Mac’s boot drive was FileVault 2-encrypted” part of the script didn’t work as intended when run on Mavericks or Yosemite. The reason it didn’t work as intended was that the script relied on Mountain Lion’s fdesetup behavior, where a non-enabled admin user (in this case, the root user) could enable the script-created “fde_locked_user” user account for FileVault 2.
When the script was run on Mavericks or Yosemite, non-enabled admin users could no longer enable accounts for FileVault 2. Testing on Mavericks and Yosemite showed that the “If the Mac’s boot drive was FileVault 2-encrypted” part of the script failed because fdesetup was not being provided acceptable authorization to enable the new fde_locked_user account that was being created by the script.
After some additional discussion and testing, it was discovered that it was possible to have the script work again as written on Mavericks and Yosemite, with one addition: the 10.8 version of the fdesetup tool.
As long as the 10.8 version of fdesetup is being used for the enablement process, it is possible to return to the Mountain Lion behavior of non-enabled admin users being able to enable accounts for FileVault 2. To take advantage of this, Google’s Macintosh Operations Team is now bundling the 10.8 fdesetup binary as part of the installer package that installs and runs their script.
Using the 10.8 fdesetup tool on 10.9.x and 10.10.x has been tested and verified to work on 10.9.x and on 10.10.0 / 10.10.1. It may break in future versions of OS X.
Update: I’ve opened a bug report with Apple about this behavior. For those that want to dupe it, the bug report ID is 18985048. For those interested in the details of the bug report, I’ve also posted the bug report to Open Radar:
http://openradar.appspot.com/radar?id=5306791864827904
Update 2: To presumably address any software distribution legal issues, Google has replaced the 10.8 fdesetup binary with a new Google-produced fdeadduser binary that has the same behavior in terms of enabling users for FileVault 2.
