Archive
FileVault 2 on OS X 10.8.x is now FIPS 140-2 Compliant
Apple announced on Friday, June 28th that the FIPS 140-2 validations for the cryptographic modules used by iOS 6 and OS X 10.8.x have now been completed. This is significant news for Mac admins who want to use FileVault 2 in government and regulated industries (such as financial and health-care institutions.)
For folks who haven’t heard of it before, FIPS 140-2 is an information technology security accreditation program run jointly by the US and Canadian governments. This program is used by private sector vendors to have their cryptographic modules certified for use in US and Canadian government departments and private industries with regulatory requirements for security.
As part of today’s announcement, Apple has released KBase articles, tools and guidance for security offices who deal with encryption:
Apple FIPS Cryptographic Modules v3.0 – http://support.apple.com/kb/DL1555
Mountain Lion: How to set up and maintain a FIPS-enabled system – http://support.apple.com/kb/HT5396
Crypto Officer Role Guide for FIPS 140-2 Compliance OS X Mountain Lion v10.8 – http://km.support.apple.com/library/APPLE/APPLECARE_ALLGEOS/HT5396/Crypto_Officer_Role_Guide_for_FIPS_140-2_Compliance_OS_X_Mountain_Lion_v10.8.pdf
FIPS Administration Tools v3.0 – http://support.apple.com/kb/DL1555
FileVault 2 is listed as being FIPS 140-2 Compliant as part of the Crypto Officer Role Guide for FIPS 140-2 Compliance OS X Mountain Lion v10.8 documentation, in the Compliant Applications and Services section.
Erasing a FileVault 2-encrypted Volume
On occasion, it’s necessary to erase a FileVault 2-encrypted volume. However, Disk Utility won’t let you erase or repartition until you unlock or decrypt.
This can be an issue for a malfunctioning FileVault 2-encrypted volume that will not let you either unlock or decrypt. To help with this, the diskutil tool provides a way to quickly delete CoreStorage volumes. This includes the ability to erase encrypted CoreStorage volumes (aka FileVault 2-encrypted volumes) without first decrypting or unlocking them.
To do this, first run the following command:
diskutil cs list
This will give you with a list of the CoreStorage volumes on your system. Unless you have a Fusion drive or multiple encrypted drives, your FileVault 2-encrypted drive should be the only one listed.
In the listing, you will want to select and copy the Logical Volume Group (LVG) alphanumeric UUID for your CoreStorage volume. The LVG should be the first UUID listed and it’s the one we want to delete.
Next, run the following command:
diskutil cs delete UUID_here
This will delete your CoreStorage volume and reformat it as an unencrypted HFS+ volume.
Installing Apple’s updated Java for OS X 2013-004 and Java for Mac OS X 10.6 Update 16 over previous versions
As part of dealing with the issues caused by the initial versions of Apple’s Java for OS X 2013-004 and Java for Mac OS X 10.6 Update 16, Apple has recommended installing the revised version of the updates overtop of the existing update in order to replace the problematic Java builds.
The fixed Java builds are the following:
Mac OS X 10.6.x: 1.6.0_51-b11-456-10M4509 (currently installed by Java for Mac OS X 10.6 Update 16)
Mac OS X 10.7.x – Mac OS X 10.8.x: 1.6.0_51-b11-457-11M4509 (currently installed by Java for OS X 2013-004)
If you’ve already installed Java for Mac OS X 10.6 Update 16, it appears that there’s no way to use the softwareupdate tool to install it again. For 10.6.x Macs that had previously installed Java for Mac OS X 10.6 Update 16 and got the problematic build, the installer will need to be downloaded from Apple and then installed on your 10.6.x Mac.
For 10.7.x and 10.8.x however, there’s a way to override the install check that softwareupdate uses which is specific to Apple’s Java updates. By setting the JAVA_INSTALL_ON_DEMAND environment variable for softwareupdate, you can force softwareupdate to install the latest Java update from Apple. This allows you to leverage softwareupdate to re-install the updated Java for OS X 2013-004 over an existing Java for OS X 2013-004 installation that included the problematic Java build.
Michael Kuron posted a script to the MacEnterprise list that I’ve modified. The modified script works pretty well in my environment and does the following:
1. Checks the current OS to see if the Mac is running Mac OS X 10.7.x or later. If not, the script will exit and display the following message:
Not supported on this version of Mac OS X
If the Mac is running 10.7.x or higher, the script runs the following actions:
2. Checks the Java version and displays the results
3. Sets the JAVA_INSTALL_ON_DEMAND environment variable
4. Uses the softwareupdate tool to check for and get the name of the latest Apple Java update for 10.7.x and 10.8.x
5. Installs the latest available Apple Java update for 10.7.x and 10.8.x
6. Checks the current Java version and displays the results
| #!/bin/bash | |
| # Original version of this script posted by | |
| # Michael Kuron <michael-lists@PHYSCIP.UNI-STUTTGART.DE> | |
| # Posted to the MacEnterprise list on June 22, 2013: | |
| # http://tinyurl.com/m8fp4ou | |
| # | |
| # This script works on Mac OS X 10.7.0 and higher | |
| # | |
| # Determine OS version | |
| osvers=$(sw_vers -productVersion | awk -F. '{print $2}') | |
| if [[ ${osvers} -ge 7 ]]; then | |
| # Checks the current Java version and displays the results | |
| java -version | |
| # Set the JAVA_INSTALL_ON_DEMAND | |
| # environment variable. This variable | |
| # overrides the install check and forces | |
| # the softwareupdate tool to install Apple's | |
| # latest Java 6 update | |
| export JAVA_INSTALL_ON_DEMAND=1 | |
| # Uses the softwareupdate tool to check | |
| # for and get the name of the latest Apple | |
| # Java update for 10.7.x and 10.8.x | |
| pkgname=$(softwareupdate --list | grep '*' | grep -i java | awk '{print $2}') | |
| # Installs the latest available Apple | |
| # Java update for 10.7.x and 10.8.x | |
| softwareupdate --install $pkgname | |
| # Checks the current Java version and displays the results | |
| java -version | |
| else | |
| echo "Not supported on this version of Mac OS X" | |
| fi |
For those interested, the script is available on my GitHub repo:
Casper Extension Attribute script to detect Java build 1.6.0_51-b11-456-10M4508
To follow up on the re-release of Apple’s Java For Mac OSX 10.6 Update 16 and Java for OS X 2013-004 updates, which fixes a problem with the previous versions of the updates, there’s a need to identify which machines got the problematic version of Java. The problematic Java build is 1.6.0_51-b11-456-10M4508 and can be identified by running the following command:
/usr/libexec/java_home -v 1.6 -exec java -version
Update – June 24, 2013:Â On further examination, it looks like Apple used two different build numbers:
Mac OS X 10.6.x: 1.6.0_51-b11-456-10M4508
Mac OS X 10.7.x – 10.8.x: 1.6.0_51-b11-456-11M4508
To help Casper admins identify which Macs have 1.6.0_51-b11-456-10M4508 or  1.6.0_51-b11-456-11M4508 installed, I’ve posted the following Casper extension attribute to my GitHub repo:
| #!/bin/sh | |
| # Determines if either of the following | |
| # Java builds are installed: | |
| # | |
| # 10.6.x: 1.6.0_51-b11-456-10M4508 | |
| # 10.7.x - 10.8.x: 1.6.0_51-b11-456-11M4508 | |
| # | |
| # This builds were installed by the first versions of | |
| # Java for OS X 2013-004 and Java for Mac OS X 10.6 Update 16 | |
| # and can cause problems for Java Swing applications | |
| # like MATLAB and Papercut. | |
| JAVA_BUILD_CHECK=`java -version 2>&1 | awk '/4508/{print $NF}' | sed '$s/.$//'` | |
| FOUND=`echo "Installed"` | |
| NOT_FOUND=`echo "Not Found"` | |
| if [ "$JAVA_BUILD_CHECK" = "1.6.0_51-b11-456-10M4508" ]; then | |
| result=$FOUND | |
| elif [ "$JAVA_BUILD_CHECK" = "1.6.0_51-b11-456-11M4508" ]; then | |
| result=$FOUND | |
| elif [ "$JAVA_BUILD_CHECK" = "" ]; then | |
| result=$NOT_FOUND | |
| fi | |
| # If either 1.6.0_51-b11-456-10M4508 or 1.6.0_51-b11-456-11M4508 | |
| # is installed, an "Installed" message is displayed. | |
| # | |
| # If neither 1.6.0_51-b11-456-10M4508 or 1.6.0_51-b11-456-11M4508 | |
| # is installed, a "Not Found" message is displayed. | |
| echo "<result>$result</result>" |
This script uses the java -version command to check the Java build version. If Java builds 1.6.0_51-b11-456-10M4508 or 1.6.0_51-b11-456-11M4508 are detected, the script reports Installed. If neither 1.6.0_51-b11-456-10M4508 or 1.6.0_51-b11-456-11M4508 are installed on the Mac, the script reports Not Found.
For those interested, the script is available on my GitHub repo:
MATLAB problems after Java for Mac OS X 10.6 Update 16 or Java for OS X 2013-004 are installed
After the latest round of Apple’s Java updates, some Java-based applications began exhibiting problems. At my shop, MATLAB was one of the applications that was affected by this.
The root cause was discussed and identified in this StackOverflow thread and appears to affect Swing applications, including MATLAB.
Symptoms
After applying Apple’s Java For Mac OSX 10.6. Update 16 to a 10.6.x Mac, or Java for OS X 2013-004 to a 10.7.x – 10.8.x Mac, MATLAB 2012b and below stops functioning correctly. You can open the program but it does not register any mouse or keyboard interaction until the window is resized.
Status as of Friday, June 21
After speaking with Mathworks support, I tested and verified the following:
MATLAB R2011a runs in Mac OS X 10.6.8, 10.7.5 and 10.8.4 with the latest Apple Java updates installed.
MATLAB R2013a runs in Mac OS X 10.7.5 and 10.8.4 with the latest Apple Java updates installed. MATLAB R2013a does not support 10.6.8.
At the moment, here are the options that appear to be available:
For 10.6.x: MATLAB users should install and use MATLAB R2011a
For 10.7.x – 10.8.x: MATLAB users should upgrade to MATLAB R2013a if possible. If not possible to upgrade to 2013a for code compatibility reasons, MATLAB users should install and use MATLAB R2011a.
Other options may include trying to roll back Java to the previous version, but that can cause other issues. I don’t recommend trying that unless neither MATLAB R2013a or MATLAB R2011a are viable options.
Update – Friday, June 21 at 5:15 PM EDT
It looks like Apple has resolved this issue by posting new versions of the Java For Mac OSX 10.6. Update 16 and Java for OS X 2013-004 installers:
Java for OS X 2013-004 – http://support.apple.com/kb/DL1572
Java for Mac OS X 10.6 Update 16 – http://support.apple.com/kb/DL1573
I’ve tested the newly rev’d Java for Mac OS X 10.6 Update 16 update on 10.6.8 and MATLAB R2012b. The new update allowed MATLAB R2012b to run normally again. I still need to test 10.7.5 and 10.8.4, but this looks promising.
Update – Friday, June 21 at 9:40 PM EDT
I’ve now tested the new revision of the Java for OS X 2013-004 update on Mac OS X 10.7.5 and 10.8.4, both times with MATLAB R2012b. The new update allowed MATLAB R2012b to run normally again on both OSs.
Enabling FileVault 2 pre-boot login screen functions from the command line
There’s a couple of functions that you can enable on your Mac that will show up at the FileVault 2 pre-boot login screen. The two functions that I’m familiar with are the keyboard input menu and a text-only login banner.
On an FileVault 2-encrypted Mac, you can go into System Preferences and enable these functions. At the next restart, they should show up at the FileVault 2 pre-boot login screen. However, if these functions were enabled using the defaults command, they may show up at the regular login window, but not FileVault 2’s login screen.
The answer seems to be that, in addition to running the defaults commands, you also need to remove certain cache filenames ending in .efires from /System/Library/Caches/com.apple.corestorage/EFILoginLocalizations. Clearing the filename.efires cache files forces the system to update the FileVault 2 pre-boot login screen. Whether this update happens right away or when the system reboots is not yet clear; if you know, please let me know in the comments.
For example, running the following commands with root privileges updates the FileVault 2 pre-boot login screen with both the keyboard input menu and a login banner:
defaults write /Library/Preferences/com.apple.loginwindow LoginwindowText "My Login Window Text Goes Here" defaults write /Library/Preferences/com.apple.loginwindow showInputMenu -bool TRUE rm /System/Library/Caches/com.apple.corestorage/EFILoginLocalizations/*.efires
On restart, the FileVault 2 pre-boot login screen should look like this, with keyboard input and login text (highlighted in red) now showing.
To remove these, you would need to boot back into the OS and run the following commands:
defaults delete /Library/Preferences/com.apple.loginwindow LoginwindowText defaults write /Library/Preferences/com.apple.loginwindow showInputMenu -bool FALSE rm /System/Library/Caches/com.apple.corestorage/EFILoginLocalizations/*.efires
On restart, the FileVault 2 pre-boot login screen should no longer have either a keyboard input menu or a login banner.
Hat tip to Josh Schripsema for figuring out that the .efires cache files need to be removed to force the refresh.
UUIDs, LDAP and FileVault 2
A little-known fact about FileVault 2 is that it uses the GeneratedUID user attribute (also known as a UUID) of an account to help identify enabled accounts. For example, when you run the fdesetup list command, you’ll see the user information appear with both the username and UUID information.
For local accounts, this isn’t an issue as the OS will properly generate a UUID for the local account. Active Directory also generally handles this correctly on Macs, so I haven’t seen UUID problems occur for AD mobile users.
Where I have heard of problems has been with non-Apple LDAP servers. If the LDAP server doesn’t provide the GeneratedUID user attribute for mobile LDAP accounts on Macs, or it does not provide the UUID in the way that FileVault 2 is expecting, you may see one or more of the following behaviors:
1. The LDAP account’s icon disappearing from the FileVault 2 pre-boot login screen – This behavior is generally caused by the GeneratedUID attribute not being set for the mobile LDAP account on the Mac. Stack Overflow has a good discussion about this issue that I recommend checking out for more details.
2. The account icon being present, but the password not matching the current password on the LDAP server – This behavior has been observed when the mobile LDAP account’s UUID does not match what FileVault 2 is expecting.
A good example of the latter behavior comes from a Mac admin who recently asked me about the issue he was seeing with passwords not updating. His shop was running an LDAP server as its directory service for its Macs and he had recently added the GeneratedUID user attribute to the accounts on the LDAP server as a fix for accounts disappearing from the FileVault 2 pre-boot login screen. Now, accounts were staying at the FileVault pre-boot login screen, but their passwords were not updating to match what was set on the LDAP server.
In discussing the problem, he mentioned that the UUIDs were using lower-case letters; did that matter? When I followed up on this, he confirmed that instead of his UUIDs looking like this:
7C9AFB0E-E06E-43FA-8E9F-1D410344D2AA
They looked like this:
7c9afb0e-e06e-43fa-8e9f-1d410344d2aa
To the best of my knowledge at the time, alphabetical characters used in Mac UUIDs were all upper-case but I didn’t know for certain that the UUIDs were case-sensitive, so I recommended that he call AppleCare Enterprise support to see if they knew.
After checking with another colleague, who confirmed that Mac account UUIDs were both upper-case and case-sensitive, he changed a test account’s UUID to be all upper-case. At that point, FileVault 2 logins for that account began working properly.
Fixing this issue
If you have an LDAP server and your mobile LDAP accounts aren’t working properly with FileVault 2, here’s what should make FileVault 2 start working properly:
1. On your LDAP server(s), make sure that there’s an apple-generateduid value for your LDAP accounts. If an apple-generateduid value exists in LDAP for a user and is mapped properly to the GeneratedUID attribute on your Macs, FileVault 2 will use the apple-generateduid value stored in LDAP for its UUID.
2. Ensure that all alphabetical characters listed in the the apple-generateduid value are upper-case.
Note: It’s very important that the locally-set UUID value and the value stored in LDAP match exactly. Otherwise, you may see a recurrence of one or both of the undesired behaviors described above
Decrypting FileVault 2 on Mac OS X 10.8.4 – Unlock first, then decrypt
As a follow-up to my earlier post about not being able to decrypt FileVault 2 from the Recovery HD partition, it looks like Apple has changed the process for how decryption works. Previously, you could run a command to decrypt on a locked FileVault 2-encrypted boot volume and it would decrypt.
As of 10.8.4, it appears that Apple now requires that the encrypted volume be unlocked first. Once it’s unlocked, then you can decrypt. See below the jump for details.
Mac OS X 10.8.4’s Recovery HD removes ability to decrypt FileVault 2-encrypted Mac
To follow on to my earlier post about needing admin rights to decrypt FileVault 2 on Mac OS X 10.8.4, it appears that Mac OS X 10.8.4’s Recovery HD partition no longer can decrypt FileVault 2-encrypted Macs. If you boot from a 10.8.4 Recovery HD partition, you can unlock a FileVault 2-encrypted boot drive but you can’t decrypt it either from Disk Utility or the command line.
Update – June 11, 2013: It looks like you will need to unlock the encrypted volume first, then you will be able to decrypt it. See this post for details.
In Disk Utility’s File menu, Turn Off Encryption… is now grayed out. Unlock “Drive Name” is still an available option.
In Terminal, attempting to decrypt with diskutil with the following commands now results a The given UUID is not a CoreStorage Logical Volume UUID error.
diskutil cs revert UUID_here -stdinpassphrase
diskutil cs revert UUID_here -passphrase
diskutil corestorage revert UUID_here -recoveryKeychain /path/to/FileVaultMaster.keychain
Unlocking from the command line continues to work.
The fact that decrypting using the institutional keychain does not work is particularly worrying. To the best of my knowledge, the only way you can decrypt using the institutional keychain is by using Recovery HD or Internet Recovery. I’ve verified that booting from an alternate 10.8.4 boot drive gives the same behavior with regards to Disk Utility and the diskutil tool.
I’ve filed bugreports at bugreport.apple.com for these issues. For those who who want to submit duplicate bugs, they are bug IDs 14099380 and 14099359.
I’ve also posted the bug reports at Open Radar:
rdar://14099380 – Unable to decrypt using diskutil while booted from Recovery HD
rdar://14099359 – Unable to decrypt using Disk Utility while booted from Recovery HD
Session videos available from Penn State MacAdmins Conference 2013
The good folks at Penn State have posted the session videos from the Penn State MacAdmins Conference 2013. The sessions slides and videos are all accessible from the Penn State MacAdmins’ Resources page at the link below:
http://macadmins.psu.edu/conference/resources/
As all the session videos have been posted to YouTube, I’ve linked my FileVault 2 session here:
Der Flounder 
Recent Comments