Slashdot Mirror
Encrypting a User's Home Directory Under Mac OS X
jnetsurfer writes "A friend of mine challenged me to see if I could place a user's home directory on a device image (DMG) under Mac OS X. Well, I decided to post my solution to the problem on the web and here, in case anyone is interested. This can be useful if you want to encrypt a user's home directory, or if you wanted to limit a user's home directory to a certain size."
PGP Disk.
The freeware version is here. I've used it before, and it works like a charm. You create a PGPDisk file on a normal volume - this contains an encrypted disk. You can then "mount" the drive after providing the correct password. I've used it in the past on NT4 and on Win2K to great effect.
Here we go, I found these unix commands in OSX 10.1.5:
...
man quota
man quotaon
man quotacheck
I have been using different encrypted file systems on Linux, mostly using the twofish algorithm. Basically, I think there are two major purposes of crypted file systems for the average geek:
1) You've got some REALLY secret information which you'd like to protect: use an encrypted file.
2) You would like to protect the information in case someone steals your computer.
In my opinion, crypting the whole system doesn't really make sence unless you're afraid of someone coming to take your computer away from you: To use the computer, you have to unlock these filesystems anyway and an intruder will be able to read your files at that time
Also, encrypted filesystems heavily slows down the system, since every read/write to disk needs some CPU. I remember getting pretty poor transfer rates, which is the reason I don't use it anymore.
The DiskImages framework and associated utilities (hdid, hdiutil) are not part of Darwin.
/System/Library/PrivateFrameworks) and plow through that.
And sadly the encryption "plugin" is embedded inside the framework rather than being external. So if you'd want to check for backdoors, you'd need to disassmble the whole DiskImages framework (in
However, since it does seem use a plugin interface, even internally, it's probably not too hard to locate just the encryption-related parts.
sudo ditto -rsrcFork /Users/USERNAME /Volumes/VOLUME-NAME/
instead, which maintains the Resource Fork information.
Why would you be storing your mp3s on an encrypted disk?
I would think personal financial documents and porn would be much more important. Of course mpeg playback would be hindered, which would be a problem.
- Log in as the user whose files you want to secure.
- Create an encrypted disk image using Disk Copy at the top level of the user's home directory. When it asks for the disk image password, be sure that the "remember password" option is checked -- this saves the disk image's password on the user's default keychain.
- Use ditto to copy over the following directories from the user's home folder onto the encrypted disk image:These are the important ones; you can copy over other items as well, but definitely don't do the entire ~/Library folder, and don't do the ~/Library/Keychains or ~/Library/Preferences folders.
- Set the disk image to automount on login by dragging it into the Login Items preferences pane.
- Use mv to shift the directories aside (e.g. mv ~/Documents ~/Documents.save) and set up symlinks onto the disk image (e.g. ln -s
/Volumes/Secure/Documents ~/Documents). - Log out and log back in again. The disk image will be automounted at login, using the password stored on the default keychain which also unlocks on login. Everything should just work!
:-D - Now for the housekeeping: delete the
.save directories you created earlier, and be sure to turn off automatic login in the Accounts preferences pane.
Why do it this way instead of the way that Joshua Gitlin wrote up? First, you don't need admin access to a machine to make it work. You may not have admin access on a company machine, or as a sysadmin you may not want to give admin access to most of your users.Second, using Joshua's method, once the disk image is mounted it's open to anyone who has admin access on that machine, whether or not you are logged in at the console. By using an automounted image with the password stored on the keychain everything is secure until you actually log in, and everything is secured once you log out.
Third, this way is a lot more convenient. If you make security too inconvenient, users will circumvent it. Instead of two logins, you only have to do one. Techincally unsophisticated users (secretaries, lawyers, vice-presidents, etc.) don't need to do anything different.
<BLATANT PLUG>
Go to Apple Training and sign up for a course or two. They're well worth the money and help me keep my job.
</BLATANT PLUG>
--Paul
psuh at apple dot com
Curriculum Developer
Techincal Training and Certification
Apple Computer
The underlying AES-128 encryption is part of the Darwin distro. Look in the Darwin sources under:
src/Security/AppleCSP/AES/
This still doesn't really address the whole question -- if there's some back door somewhere higher up the stack in the disk mounting code, you won't find it here, but it's part of the solution. Validate the AES-128 code, then treat the encrypted disk image as a black box (using a simple password, without loss of generality) and see if you can decrypt the image by hand or using a util that you write yourself.
OK, I work for Apple so you really can't fully trust me on this, but I certainly don't know of any intentional back doors in this code.
--Paul
psuh at apple dot com
Curriculum Developer
Technical Training and Certification
Apple Computer
One more thing -- people have been commenting/asking about the speed of access. The algorithm for AES-128 on MOSX 10.2 has been heavily optimized. There is basically little or no additional overhead when using an encrypted disk image vs. an unencrypted disk image.
--Paul