Articles‎ > ‎

FileVault Considerations

posted Dec 18, 2008, 10:19 AM by Philip Rinehart   [ updated Dec 18, 2008, 10:19 AM by Greg Neagle ]
Written by Greg Neagle   
Monday, 26 February 2007
Data security is a hot topic in Enterprise IT these days. With growing numbers of company employees using laptops instead of traditional desktops, the risk to company data is greater than ever. If a laptop is stolen or lost, the replacement cost of the hardware may be a pittance compared to the value of the data.

This is why many companies are mandating some sort of data encryption for company laptops. If a laptop is then stolen or lost, the data would be inaccessible to the thief. Mac OS X includes a feature Apple calls "FileVault," which secures users' home directories with AES-128 encryption.

This article will attempt to present some of the issues you may encounter when implementing and supporting FileVault in an enterprise environment, and techniques to use to deal with some of these issues.

FileVault - encryption for user data

FileVault works by storing a user's files in an encrypted disk image file. Disk images are familiar to most OS X users -- many enterprises set up their OS X machines by restoring a disk image to the machine's hard drive, and many software installers are distributed in the form of disk image files. FileVault uses a disk image that is encrypted with the user's login password. When the user logs in, his or her password is used to unlock the disk image. The image is then mounted at /Users/ and for the most part, looks and behaves like a normal user home folder.

There are two primary risks associated with implementing FileVault for your users. The first is that they forget their password and cannot access their data. Since the password is the same as the login password, this seems an unlikely scenario, but there are other ways a user could lock themselves out of a FileVault-protected account. It's not uncommon for organizations to implement a web page that all users can go to to change their password. If, however, a user with a FileVault-protected account does this, the FileVault disk image is not updated with the new password -- this only happens if you use the Accounts preferences pane to change your password. Apple has provided a way for administrators to unlock FileVault disk images - this is the FileVault "master password". More on this later.

The second primary risk associated with FileVault is data corruption. Since FileVault-protected home directories are encrypted disk images, and since a disk image is a single file, corruption of that single file can lead to the loss of the entire FileVault home directory. This type of corruption is rare, but is possible. Your best defense is backups. We implement both Portable Home Directories and FileVault on our laptops. Since the synchronization process of Portable Home Directories runs only when the user is logged in, only changed files are copied to/from the network home. FileVault protects the data on the local machine from theft, and Portable Home Directories ensure that the crucial parts are synced to the users' network home directories, which are in turn backed up to tape. Backups are always important for enterprise data, but they are even more important for FileVault-protected data.

Preparing for FileVault

Before implementing FileVault in your organization, you might want to do some prep work. The most important bit of prep work is to set the FileVault master password for all your machines. This is the password you can use to get access to a FileVault-protected disk image if the user's password has been forgotten or is otherwise not available. In order to be useful, you almost certainly want this master password to be the same on all the machines you manage.

Image

To do this, you'll create a FileVault Master password on one machine, and then copy certain files to all your managed machines. Open the Security preference pane and click "Set Master Password". Since this will be deployed to all your managed machines, and since changing it (and propagating that change to existing FileVault-protected accounts) is difficult, make sure it's a non-trivial password, and do not make it the same as any other admin or root password you have in use. Use the Password Assistant to check on the quality of your chosen password. Click OK to create the master password.

Two new files are created in /Library/Keychains: FileVaultMaster.cer, and FileVaultMaster.keychain

To implement the FileVault Master Password on all the machines you manage, simply install these two files on all your managed machines. You can use any method to do this (put them in your install image, using ARD, radmind, FileWave, etc), but make sure they are in place BEFORE FileVault is turned on for any accounts on a given machine. If FileVault has been turned on before these FileVaultMaster files are installed, the pre-existing FileVault-protected accounts cannot be unlocked using the FileVault Master Password you just created.

The second most important preparation task is to ensure you have a method to backup user's home directories. I recommend implementing Portable Home Directories, and then backing up the network home directories, but depending on your environment, you may decide to use something like Retrospect to directly backup user home directories.

You may or may not want to implement the next preparation task: turning on password hints. If your users forget their passwords, in order to get a prompt to allow an administrator to unlock the account using the master password, "Show password hints" must be turned on in the Accounts preference pane, under "Login Options", or if you are managing your clients via MCX, in Workgroup Manager, set up a Computer List, and manage this Preference under Login->Login Window, checking "Show password hint after 3 attempts to enter a password". One last option is to do this via command-line, perhaps as part of a script:

sudo defaults write /Library/Preferences/com.apple.loginwindow RetriesUntilHint 3

Additionally, the MasterPasswordHint key must exist in the defaults keys for /Library/Preferences/com.apple.loginwindow. Normally, this is set when you create the FileVault master password via the Security preferences pane. But if you simply distribute the /Library/Keychains/FileVaultMaster.cer and /Library/Keychains/FileVaultMaster.keychain files to other machines you manage, this key will probably not be set.

sudo defaults write /Library/Preferences/com.apple.loginwindow MasterPasswordHint ""

will do the job. (It's OK to have an empty hint, but the key must exist.)

Enabling password hints is itself considered a security risk in many organizations, so consider if you really want to do this. If you don't, there is no way from the GUI for an admin to recover a FileVault-protected home directory -- but an admin can still do so from the command line.

The final preparation task is training. Train your tech support staff on FileVault, and provide a method for your users to find out more about FileVault as well. The better you document and train, the higher users acceptance will be.

Local preparation

There are a few things you can do on the local machine before turning on FileVault that will increase your odds of success. First, make sure the startup disk is healthy. Run Disk Utility to verify, and if needed, repair the startup disk. Second, minimize the amount of data that needs to be copied to the encrypted disk image - delete unneeded files. Empty the trash. rm -R /Users/username/Library/Caches/* to get rid of cache files. If you use Norton/Symantec AntiVirus, turn off AutoProtect. This will speed up creation of the new disk image and avoid issues where Norton AutoProtect interferes with disk image creation.

 

Turning on FileVault

Apple does not support an automated way to turn on FileVault. It would be fantastic if, as with Portable Home Directories/Mobile Accounts, admins could configure a machine so that the next time a user logs in, they would be prompted to enable FileVault protection. This is not currently possible. Unless you are willing to do some fancy login hook scripting, FileVault must be turned on manually at each machine.

When FileVault is enabled for an account, an encrypted disk image is created, everything is copied from the "unencrypted" home directory to the encrypted disk image, and finally the items in the unencrypted home directory are deleted. This means that you must have more free space on the hard drive than the size of the home directory you are encrypting. If the user has 60GB of data in his or her home directory, there needs to be more than 60GB free on the hard drive. Exactly how much more is needed is unclear.

Turning on FileVault is straightforward. Log in as the user for which you'd like to turn on FileVault. In the Security preferences pane, click the "Turn On FileVault..." button. If the preference pane is locked, you'll be asked to enter an admin password (which may effectively prevent users from turning on FileVault by themselves). You'll then be prompted for the user's account password (which may effectively prevent admins from turning on FileVault for users without their involvement). You'll be presented with one last dialog, informing you of the dire consequences that await you should you forget your login password and lose the master password.

Image

Of note, in this dialog is a check box labled "Use secure erase". You should check this. If you do not, when OS X removes the original home folder after creating the FileVault disk image, it is possible to recover some or all of the data using an unerase or file rescue utility. This could defeat much of the purpose of turning on FileVault.

Once you click "Turn On FileVault" in this final confirmation dialog, the current user will be logged out and the FileVault conversion process will start. If anything interrupts the logout (such as cancelling when asked what to do with an unsaved document), the FileVault conversion will be cancelled and you'll have to visit the Security preference pane to start again from the beginning.

The actual FileVault conversion process can be quite fast, or quite slow, depending on how much data is in the user's home directory. In our case, we have a (relatively) small network home directory quota, and so endeavor to keep our users within that quota locally as well so Portable Home Directories work smoothly. In our default setup, we do not synchronize ~/Movies, ~/Music, or ~/Pictures with the network home. In practice, this can mean that these directories can grow quite large on our laptop user's homes (especially the ~/Music folder). You'll need to decide if you want to keep this kind of thing encrypted in FileVault, or possibly move things like iTunes Music outside of the home folder and then symlink. Either decision has its consequences:

  1. Keeping Movies, Music, and Pictures in a FileVault-protected home:
    • Pros:
      • Don't need to treat this data specially
      • Data is in its "expected" location, so no special training needed
      • If there is company data put in these folders for any reason, it's encrypted
    • Cons:
      • Makes the home dir larger, increasing time and space needed for FileVault conversion
      • FileVault space reclamation will take longer
      • If this data is not backed up and the FileVault image gets corrupted, user data can be lost
  2. Moving Movies, Music, and Pictures outside of the FileVault-protected home
    • Pros:
      • Home directory is smaller, so faster FileVault conversion and less free space needed
      • FileVault space reclamation is faster
      • Files are still accessible if the FileVault image get corrupted, aiding manual data recovery
    • Cons:
      • More complex setup can lead to user and technician confusion and error
      • Company data stored in these folders is not encrypted
A third option, not detailed here, would be to move these folders outside of the FileVault-protected home, but into a separate encrypted disk image. In my opinion, this adds even more complexity and has few advantages over choice #1.

If the FileVault conversion process fails for any reason, the partially-created encrypted disk image is removed, and the original home directory is left untouched. Possible reasons for failure of the FileVault conversion are a full hard drive; drive or file system errors or failures; and anti-virus scanning of the drive image. I've also seen aliases to unavailable volumes like unconnected FireWire or USB drive cause problems, though I don't understand why. I continue to look for good logging information for a FileVault conversion, but so far haven't found much.

Turning FileVault off

If, for whatever reason, you wanted to turn FileVault off for an account, you can do so with the Accounts preference pane while logged in as the appropriate user. The process is very similar to turning on FileVault - you'll need an equivalent amount of free space on the hard drive. You'll probably also need an admin password and the user's login password.

 

Living with FileVault

Once turned on, a FileVault-protected home directory is relatively transparent in operation to the user when he or she logs in. The main clue you'll see when using a FileVault-protected account is the FileVault icon replaces the "normal" home icon in the Finder.

Image

It's important to realize that while the user is logged in, any other user that has access to the machine (either physically or over the network, say via SSH) and that has root or sudo privileges can still access the files in the user's home directory. This can be a good thing, or a bad thing, depending on your point of view. Only when the user is logged out are the files inaccessible.

Some applications may behave poorly with FileVault-encrypted home directories. Some examples:

  • FinalDraft 7 would crash at startup when launched from a FileVault-protected account; this is fixed in the current version (7.1.3 ) (See http://media.finaldraft.com/downloads/readme_fd713.txt).
  • Some Automator actions fail on FileVault-protected accounts (see http://www.macosxhints.com/article.php?story=20051020203919140)
  • iMovie has performance issues with FileVault. (See http://docs.info.apple.com/article.html?artnum=93460). FinalCut Pro does as well (See http://docs.info.apple.com/article.html?artnum=93454). Other applications that need high-performance disk access may be similarly affected.
  • There are certainly other applications that have issues. Be sure to test the important applications you use.

Disk image compaction

Since FileVault makes use of what Apple calls "Encrypted Sparse Disk Images", the image files are very space-efficient. But as items are added and deleted, these image files can grow bigger than they need to be and some housekeeping must be done to recover unused space. If this was not done, eventually the disk image file would grow to fill all available hard drive space. So periodically at logout, the user is notified that the image is using more space than is needed and asks for permission to recover the unused space. If the user is in a hurry to shutdown, restart, or log back in, they can cancel this housekeeping task - but they shouldn't put it off forever! Depending on the size of the home directory and the amount of recoverable space, recovery can be quite fast, or take a very long time. Train your users to treat the computer with kid gloves during the space recovery - if they were to get impatient and turn off the computer or force a restart during the recovery process, they could corrupt the disk image.

FileVault Recovery

If the user forgets the password, and you have the FileVault Master Password (and keychain), you can access the contents of the FileVault disk image. You could then copy the contents and recover the user's data.

If password hints are turned on, after three unsuccessful attempts, a password hint will be shown, if one is set in for the user's account. If there is no user password hint, or the user still enters an incorrect password, the loginwindow will change, showing text directing the user (or an admin) to enter the FileVault master password to reset the user's password and to unlock FileVault.

In practice, I've found this to work only with purely local accounts protected with FileVault. Mobile accounts (those with Portable Home Directories) never show a password hint or the Master Password prompt, at least when testing in my environment. Fortunately, there is another way to unlock a FileVault-protected home directory: via the command-line.

Command-line FileVault Recovery

Here's how to recover the disk image from the command line. Log in as root, or with an account that has sudo privileges to act as root (Admin accounts by default on OS X have this ability):

 

[troup:~] gneagle% sudo security unlock-keychain /Library/Keychains/FileVaultMaster.keychain
password to unlock /Library/Keychains/FileVaultMaster.keychain: 
[troup:~] gneagle% sudo hdiutil attach /Users/someuser/someuser.sparseimage -owners on -recover /Library/Keychains/FileVaultMaster.keychain 
/dev/disk1 Apple_partition_scheme 
/dev/disk1s1 Apple_partition_map 
/dev/disk1s2 Apple_HFS /Volumes/someuser 

The "key" here is that you must unlock the FileVaultMaster keychain before you can use it to unlock the disk image. Once the disk image is mounted, you can then copy the data elsewhere. Here is a step-by-step session where I unlock the image, copy the contents back to the users' home, and modify the Directory Services entry so that the account uses the now unencrypted home:

First, lets move the FileVault-encrypted home off to the side:
[troup:~] gneagle% sudo mv /Users/someuser /Users/.someuser

Now, unlock the FileVaultMaster keychain:
[troup:~] gneagle% sudo security unlock-keychain /Library/Keychains/FileVaultMaster.keychain
password to unlock /Library/Keychains/FileVaultMaster.keychain:

Next, mount the .sparseimage file using the FileVaultMaster keychain instead of the password, and make sure owners/permissions are on:
[troup:~] gneagle% sudo hdiutil attach /Users/.someuser/someuser.sparseimage -owners on -recover /Library/Keychains/FileVaultMaster.keychain
/dev/disk1 Apple_partition_scheme 
/dev/disk1s1 Apple_partition_map 
/dev/disk1s2 Apple_HFS /Volumes/someuser

Copy the data from the mounted disk to the user's home directory (this will create a new directory at /Users/someuser):
[troup:~] gneagle% sudo ditto /Volumes/someuser /Users/someuser

Unmount the disk image:
[troup:~] gneagle% sudo hdiutil detach /Volumes/someuser
"disk1" unmounted.
"disk1" ejected.

Modify the account info in Directory Services so that the home no longer points to the .sparseimage:
[troup:~] gneagle% sudo dscl . delete /Users/someuser HomeDirectory

The user should now be able to log in and access their (now) unencrypted home directory. The FileVault .sparseimage file is still in /Users/.someuser; once we verify everything is okay, we should remove it:
[troup:~] gneagle% sudo rm -R /Users/.someuser

 

Other recovery options

If the user simply changed their password somewhere other than using the Accounts preferences pane on the machine with the FileVault-encrypted home directory, you have another recovery option. Simply have the user change their password back to the previous password. They then should be able to login to the FileVault-encrypted account and access their data.
Our currently recommended procedure for FileVault users to change their password is:
  1. Use the Accounts preferences pane on the machine with the FileVault-protected account to change their password. This updates the password in the FileVault disk image, and changes their locally-cached and LDAP passwords.
  2. Use our internal web page to "change" their password (changing it to the exact same password chosen in step 1). This changes the password in a few other places we store it. We hope in the near future to be able to eliminate step 2 as we continue to integrate and consolidate our directory services infrastructure.

If your organization expires passwords, you may want to test to be sure that the FileVault password is updated when the user is prompted to change their password. My testing was inconclusive - when I marked an account as having an expired password, or required a new password at next login, I simply could not log in at all.

 

Changing the FileVault disk image password

If the user has changed their password externally, and there's no way to change it back, you can change the password for the FileVault disk image to match:

 

[troup:~] gneagle% sudo security unlock-keychain /Library/Keychains/FileVaultMaster.keychain
password to unlock /Library/Keychains/FileVaultMaster.keychain: 
[troup:~] gneagle% sudo hdiutil chpass /Users/someuser/someuser.sparseimage -recover /Library/Keychains/FileVaultMaster.keychain -newstdinpass
Enter new disk image passphrase:

Be careful, as you are not prompted to confirm the new password. If you make a mistake, just run hdiutil chpass again.

A final option if all else fails is to simply abandon the FileVault-encrypted disk image and use data from backups or the network home directory. Obviously, this is a last resort. You'll need to either edit the local account info using NetInfo Manager or the command-line dscl utility, removing the home_loc (NetInfo) or HomeDirectory (dscl) attribute. This will cause the account to revert to using the NetInfo "home" or DirectoryServices "NFSHomeDirectory" path (typically /Users/shortname) and to ignore the FileVault disk image. If you are using Portable Home Directories, you could move the .sparseimage file aside (for possible future recovery attempts), delete the local account entirely, then recreate the Portable Home Directory from scratch.

 

Additional considerations

FileVault only protects the contents of a users' home directory when the user is not logged in. When a user logs in, the encrypted disk image containing the user's files is unlocked an made available to the OS. So if a user is logged in, and their laptop is stolen, their data is still at risk. You can mitigate more of this risk by enforcing "Require password to wake this computer from sleep or screen saver" in the Security preference pane. Assuming the laptop is closed when it is stolen (or the thief closes it), when opened, it will ask for the user's password. The thief then is forced to shutdown or restart the computer, which relocks the FileVault disk image, securing its data. (This, of course, assumes you have automatic login turned off.) For further protection, enforce a short screensaver timeout as well.

An additional vulnerability is the Virtual Memory swap files. The OS uses these to store items from memory that are not currently in use, in order to provide more memory to active processes. The swap files could contain private data or confidential information. You can close this vulnerability by checking "Use secure virtual memory" in the Security preference pane. To manage this for all our machines, I use this script, which runs at startup:

 

#!/usr/bin/perl -w
# enableSecureSwap
#
# a script to check if secure swap is enabled
# on laptops, and turn it on if needed
# Greg Neagle, Disney Animation Studios
use strict;

my $IS_LAPTOP = `/usr/sbin/system_profiler SPHardwareDataType | grep "Machine Model" | grep "Book"`;
exit unless ($IS_LAPTOP);

# turn on secure swap (Virtual Memory)
if (!`grep ENCRYPTSWAP=-YES- /private/etc/hostconfig`) {
   system "grep -v ENCRYPTSWAP /private/etc/hostconfig > /private/etc/hostconfig.tmp";
   system "echo 'ENCRYPTSWAP=-YES-' >> /private/etc/hostconfig.tmp";
   rename "/private/etc/hostconfig.tmp", "/private/etc/hostconfig";
   # note: this change won't take effect until the next reboot.
}

The /Users/Shared folder exists by default on OS X as a shared space all users of a machine can access. Some third party applications absolutely require that this folder exists in order for the applications to run. This folder is _not_ protected by FileVault, as it's not part of a user's home directory. You'll need to decide what to do about this folder. If some of the applications you use require it, and you need to protect it, one solution might be to replace it with a symlink to the user's home directory, like so:

[troup:~] gneagle% mkdir /Users/someuser/Shared
[troup:~] gneagle% ln -s /Users/Shared /Users/someuser/Shared

This might be an acceptible solution on a laptop, which generally has a single user. Obviously, this technique won't work unmodified for a multi-user machine.

Finally, many processes write temporary items to /tmp, and this could include user data. This is more difficult to secure, as it is used by processes even when no-one is logged into the console. I have no specific recommendations on securing this.

 

Conclusion

Hopefully, this article has given you some tools you can use, some prectices you can implement, and some items to explore to make your FileVault deployment successful for your organization.

Greg Neagle
Sr. Systems Engineer
Disney Animation Studios
Burbank, CA

Last Updated ( Sunday, 20 May 2007 )
Comments