Volume Number: 24 (2008)
Issue Number: 09
Column Tag: MacEnterprise
By Greg Neagle, MacEnterprise.org
Data security is a hot topic in Enterprise IT these days. As laptop usage increases, pushing out 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 stored on the laptop's hard drive.
Therefore 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. "Whole–disk encryption" is a direction many companies are moving toward, but as of this writing, there are no shipping products that will encrypt a Mac boot volume. So Mac administrators must work with what is available: a technology Apple calls "FileVault," which secures users' home directories with AES–128 encryption.
In part one of this series, we covered preparation and implementation of FileVault in an enterprise environment.
In this installment, we'll examine some of the issues you may encounter when implementing and supporting FileVault in an enterprise environment, and techniques and tools to use to deal with some of these issues.
Once encrypted, 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.
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, because the encrypted disk image is unmounted.
FileVault–protected home directory in the Users folder
This points out a security hole: what if a laptop is stolen while the user is logged in? In fact, this is a very likely scenario Đ many users rarely log out or shut down; instead they simply put the machine to sleep by closing the lid. If a machine is stolen in such a state, the FileVault disk image is unencrypted and mounted, so the user's files are accessible.
To close this security hole, you'll want to enforce the Require password to wake this computer from sleep or screen saver setting found in the Security preference pane.
Security preference pane
This setting can be enforced using MCX policy. If a thief were to take a laptop configured in this manner, the password request would prevent them from accessing the logged–in user's files.
Some applications may behave poorly with FileVault–encrypted home directories. Some examples:
Final Draft 7 would crash at startup when launched from a FileVault–protected account; this was fixed in version 7.1.3:
http://media.finaldraft.com/downloads/readme_fd713.txt
http://www.macosxhints.com/article.php?story=20051020203919140
iMovie and GarageBand have known performance issues with FileVault home directories:
http://docs.info.apple.com/article.html?artnum=93460
http://docs.info.apple.com/article.html?artnum=42964
http://docs.info.apple.com/article.html?artnum=93699
http://docs.info.apple.com/article.html?artnum=93618
http://docs.info.apple.com/article.html?path=GarageBand/4.0/en/6567.html
FinalCut Pro and Express have performance issues as well:
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.
In most cases, there are workarounds for the FileVault issues, but most of the workarounds open up data security issues once again, as they rely on moving data to a non–encrypted part of the disk. You'll need to decide how to handle this.
In 10.4 (Tiger), 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 is not done, eventually the disk image file will grow to fill all available hard drive space. 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, which could then lead to total loss of the home directory contents!
With 10.5, the user experience is improved. FileVault now makes use of "sparsebundles", in which the disk image data is kept in a collection of files inside an enclosing directory. This revised format has several advantages, but the one relevant here is that unused space recovery is much, much faster. In fact, it's so fast that Apple no longer asks at logout if you want to reclaim unused space Đ it just goes ahead and does it at each logout.
A related issue: a user sees their hard drive is getting too full. They delete a bunch of files from their home directory and empty the trash. They are confused when there is no change in the available space on the hard drive. This is because the space is not reclaimed from the disk image file until logout (and, in Tiger, after the user agrees). Your support staff should be made aware of this issue, as it can cause much confusion.
If the user forgets their password, or changes their login password in a way that doesn't also update the FileVault password, they may find themselves locked out of their FileVault home directory. If you have the FileVault master password (and keychain), you can reset the password on the FileVault disk image.
If password hints are turned on, after three unsuccessful attempts, a password hint will be shown, if one is set for the user's account. If there is no user password hint, or the user still enters an incorrect password, the login window will change, showing text directing the user (or an administrator) 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.
Here's how to change the FileVault password 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). Watch the line breaks Đ in the example below, all commands are entered as one single line:
[mbp:~] gneagle% sudo security unlock–keychain /Library/Keychains/FileVaultMaster.keychain password to unlock /Library/Keychains/FileVaultMaster.keychain: <enter FileVault master password> [mbp:~] gneagle% sudo hdiutil chpass /Users/someuser/someuser.sparseimage –recover /Library/Keychains/FileVaultMaster.keychain Đnewstdinpass Enter new disk image passphrase: <enter your desired password>
Be careful, as you are not prompted to confirm the new password. If you make a mistake, just run hdiutil chpass again.
A common scenario requiring the FileVault password to be changed is when the user changes their login password by some method other than the Mac OS X Accounts preference pane. For example, many organizations provide a web page to change network passwords. If a user changes their network account password in this manner, the FileVault password cannot be updated. The same issue occurs if the user uses multiple machines and changes their password on a machine other than the one with the FileVault–protected home directory.
Under Tiger, this password mismatch almost always required administrator assistance to recover from. Leopard makes users' and administrators' lives easier in this regard: if a user authenticates at the login window with their correct network credentials, but the FileVault disk image cannot be unlocked with the current network password, the OS will now display a dialog asking the user to enter their previous login password. If the entered password can unlock the FileVault disk image, the disk image password is updated, and the user is able to login.
You may have a need to determine if FileVault is turned on for a particular user of a machine. Since waiting for the user to step away from their machine so you can peek at the Security preferences pane while they are logged in isn't always practical, it's helpful to have another way.
The most accurate way to determine if FileVault is enabled is to use dscl:
[mbp:~] gneagle% dscl . read /Users/gneagle HomeDirectory HomeDirectory: <home_dir><url>file://localhost/Users/gneagle/gneagle.sparsebundle</url></home_dir>
Note the file:// URL and the filename ending with ".sparsebundle" (or ".sparseimage" in Tiger). This is your proof positive that the account is using a FileVault–protected home directory.
You might be a bit confused here. If the sparsebundle (or sparseimage) is stored inside /Users/username, how can it be made available at /Users/username when the user logs in?
When the user is not logged in, the /Users directory looks something like this:
[mbp:/Users] root# ls –al drwxr–xr–x 7 root admin 238 May 2 16:01 . drwxrwxr–t 46 root admin 1632 Apr 25 16:14 .. –rw–rŃrŃ 1 root wheel 0 Sep 23 2007 .localized drwxrwxrwt 24 root wheel 816 Apr 30 14:46 Shared drwxrŃrŃ 115 gneagle staff 3978 May 2 12:28 gneagle
The gneagle.sparsebundle file is inside the gneagle directory. But once gneagle logs in, the /Users directory looks like this:
[mbp:/Users] root# ls –al drwxr–xr–x 7 root admin 238 May 2 16:01 . drwxrwxr–t 46 root admin 1632 Apr 25 16:14 .. dr–xŃŃŃ+ 6 gneagle staff 204 Apr 30 12:06 .gneagle –rw–rŃrŃ 1 root wheel 0 Sep 23 2007 .localized drwxrwxrwt 24 root wheel 816 Apr 30 14:46 Shared drwxrŃrŃ 115 gneagle staff 3978 May 2 12:28 gneagle
Note the new ".gneagle" directory. Further investigation will show the gneagle.sparsebundle file is now inside the .gneagle directory, and the disk image is mounted on /Users/gneagle:
[mbp:/Users] root# mount /dev/disk0s3 on / (hfs, local, journaled) devfs on /dev (devfs, local) fdesc on /dev (fdesc, union) map –hosts on /net (autofs, automounted) map auto_home on /home (autofs, automounted) /dev/disk1s2 on /Users/gneagle (hfs, local, nodev, nosuid, journaled)
So let's put this knowledge to use.
On rare occasions on Tiger machines, you may encounter a situation where a FileVault–protected user cannot log in. You login to the machine with an admin account, and look in the /Users/username folder, and find the sparseimage file missing! Instead of panicking, you use your hard–earned systems administration knowledge, and you remember to look for a ".username" directory under /Users. You find it, and inside, the username.sparseimage file. You then move the sparseimage file back into the /Users/username directory, remove the /Users/.username directory, and tell the user to try to log in. They succeed, and you are a sysadmin hero.
What has happened is that the machine crashed while the user was logged in, and the sparseimage file was not moved back into /Users/username, as it would be after a normal logout. When this happens, Tiger does not always fix things after the reboot, so you may need to help things along.
Thus concludes our look at implementing FileVault in an enterprise environment. We've looked at preparation tasks and deployment options. We've identified some common issues and user experiences, and demonstrated some tools and strategies to deal with these. You now have the knowledge to confidently help protect your organization's private data and intellectual property with FileVault's home directory encryption.
Greg Neagle is a member of the steering committee of the Mac OS X Enterprise Project (macenterprise.org) and is a senior systems engineer at a large animation studio. Greg has been working with the Mac since 1984, and with OS X since its release. He can be reached at gregneagle@mac.com.
