Encrypting a User's Home Directory Under Mac OS X 87
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."
Re:Interesting (Score:2, Funny)
Re:Another CmdrTaco shill for Steve Jobs (Score:2)
Cool article--one concern/question: (Score:3, Interesting)
Re:Cool article--one concern/question: (Score:4, Informative)
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.
Re:Cool article--one concern/question: (Score:4, Informative)
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.com]
Apple Computer
Re:Cool article--one concern/question: (Score:2, Funny)
Encrypted files systems... (Score:3, Interesting)
Re:Encrypted files systems... (Score:4, Informative)
The freeware version is here [pgpi.org]. 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.
Re:Encrypted files systems... (Score:3, Interesting)
Re:Encrypted files systems... (Score:3, Informative)
Using OSX' diskimages however is free-as-in-beer, and probably a bit more flexible. Can you even mount a PGPdisk from the commandline on OSX ?
What I meant was... (Score:1)
Re:What I meant was... (Score:2)
Re:What I meant was... (Score:1)
Encrypting the OS should prevent someone with physical access to the disk it is on from tampering with it without you noticing.
Think of someone somehow inserting password-snooping software into the OS (temporarily installing the disk in another computer if needed), waiting for you to access your encrypted files, then returning to snag your files using your very own perfectly valid passwords...
Seems far-fetched? This very scenario occurred at a University computer lab, forcing sysadmins to install hardware encryption devices in all the PC's...
Re:What I meant was... (Score:3, Informative)
Re:What I meant was... (Score:2)
Re:What I meant was... (Score:2)
Re:Encrypted files systems... (Score:1)
Re:Encrypted files systems... (Score:3, Informative)
I doubt that it is worth the trouble though. You generally only need to encrypt data, not executables.
Joe
limit a user's home directory to a certain size ? (Score:1)
At least Apple must have thought of this when creating os x server. And if it's in the server version, it should be easy to put in the standard edition.
Re:limit a user's home directory to a certain size (Score:5, Informative)
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.
Re:Linux (Score:3, Informative)
http://weigand.home.texas.net/efs.html [texas.net]
Of course, there are Linux distributions that does it out of the box. I use Suse that does this just fine
So how strong is AES-128? (Score:3, Insightful)
The NIST has a white paper on AES [nist.gov] which announces that the Rijndael method was the official AES algorithm and that Rijndael is designed with some flexibility in terms of block and key sizes.
Apparently 128 bit AES allows for a possible 3.4 x 10^38 possible keys which (correct me if I'm wrong here) puts it somewhere between DES and triple-DES. (?)
Can any Mac users comment on the limitations that are imposed on your choice of a passphrase?
Basically, I'd like to know how strong a method is this. Is it keep your little sister from reading your diary encryption, or more along the lines of if the Feds busted you they couldn't crack open your data with any computers due out in ten years type of encryption.
OK It's strong. (Score:3, Informative)
Assuming that one could build a machine that could recover a DES key in a second (i.e., try 255 keys per second), then it would take that machine approximately 149 thousand-billion (149 trillion) years to crack a 128-bit AES key. To put that into perspective, the universe is believed to be less than 20 billion years old.
Re:So how strong is AES-128? (Score:3, Informative)
However, the keyspace of an algorithm is only one of its strengths. It's only relevant if brute force is the fastest way to crack the cipher, which is very rarely the case. In the case of DES, it was refined by the oft-maligned NSA to resist differential cryptanalysis, leaving it resistant against all but brute-force until linear cryptanalysis was 'discovered' in the mid-90s. (To those who still believe the NSA weakened DES, go read your Schneier.)
AES-128 is a new algorithm, but feels good. Brute-forcing a 128-bit keyspace would take several centuries, even taking into account Moore's law, so the difference between it and 3DES's 168 bits isn't relevant. Moreover, there are known exploits against 3DES (even if they aren't terribly helpful), whereas massive scrutiny by cryptanalysis worldwide (while Rijndael was becoming AES) has turned up nothing so far. This doesn't mean there won't be exploits, but it means that the chances that Shamir or one of the other hotshot cryptanalysts is going to bring out a paper tomorrow that invalidates all your work are very small.
So: AES-128 will keep your sister from reading your diary. Unless you believe the NSA has some sort of amazing quantum computing that's forty years beyond consumer tech (which I really, really don't), AES-128 is also likely to keep your files safe from the gimmies for several decades.
Although why the NSA would be interested in, say, my homedir, is beyond me -- the most likely person trying to crack my encryption is probably a jealous girlfriend.
Re:So how strong is AES-128? (Score:1)
Well, I wouldn't be so sure about that.
http://www.counterpane.com/crypto-gram-020
Ditto... (Score:4, Informative)
sudo ditto -rsrcFork /Users/USERNAME /Volumes/VOLUME-NAME/
instead, which maintains the Resource Fork information.
Re:Ditto... (Score:5, Informative)
I just realized that because of a behavior of ditto, you'll want it to be:
sudo ditto -rsrcFork /Users/USERNAME /Volumes/VOLUME-NAME/USERNAME
Sorry for the little oversight :)
Do it automatically? (Score:1)
I wonder if it's possible to write a Login Plugin to automatically mount the encrypted homedir using the password entered by the user. That would make the system completely transparent, while still being secure (assuming the password is good): If someone uses any other means (= security hole) to gain access to the account, the system won't have the password it needs to decrypt the homedir, so even gaining root access wouldn't help.
(This would be very similar to the way Keychains are already handled: if your login password is equal to the passphrase of your default keychain, it is automatically unlocked when you log in)
Re:Do it automatically? (Score:2, Interesting)
The LoginHook is run as root and is passed the user name as $1. We use it to create dynamic AFS mounts on login now, so I don't see why it would work in this case.
Re:Do it automatically? (Score:2)
Thanks.
Re:Do it automatically? (Score:2, Informative)
Apple hasn't written too much, but they do have this doc [apple.com].
Also, macosxlabs.org has written a doc [macosxlabs.org] that fills in some gaps. If you are going to be doing a lot during login/logout, you might want to checkout iHook [umich.edu] from the University of Michigan. It's a great little tool that give a GUI to boring old shell scripts.
Probably not (Score:1)
--Fred
Compress the user directory... (Score:1)
Not fast (Score:1)
Re:Not fast (Score:5, Insightful)
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.
Encrypting porn ? (Score:2, Insightful)
(Of course, this is only general thoughts and not a personal attack on the poster. I encrypt my financial information too
Re:Encrypting porn ? (Score:2)
I was just joking on what some people would consider "important documents".
Re:Not fast (Score:2, Insightful)
When the RIAA/MPAA/whoever carts your ass off to jail for having MP3's of songs you don't own the CD's to....you'll wish you had encrypted your music.
What's the point? (Score:2, Interesting)
I don't see how this can make things more secure - since anybody with proper permissions can access the contents of the mounted image via the mount point just as well as when the data was in
It would make some sense if the image would be mounted only at login (and unmounted at logout), but this is not possible with this hint either. Out of top of my head, I can't think of a way to do this.
Re:What's the point? (Score:2, Interesting)
That way, you, your S.O. and the kids could have their own private porn collections.
Exisiting scripts (Score:1)
Roger Jolly's Encrypt and ".secret" scripts in AEP and the Mac OS X Encoding Plethora [mac.com] seem to have similiar functionality. I'm guessing these tools will not hide your directory structure or file names, but if I'm not mistaken, they will encrypt the individual files in semi-transparent manner.
Does anyone have experience using these? Is the encryption function useful?
Think different -- a better way to do it (Score:5, Informative)
- 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 [apple.com] 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
Re:Think different -- a better way to do it (Score:1)
Apologies in advance if this is a newbie question that I should know.
-73 because it's about prime.
Re:Think different -- a better way to do it (Score:3, Interesting)
Re:Think different -- a better way to do it (Score:3, Insightful)
A pretty good way to make a difficult to crack but easy to remember password is to string together two words with some punctuation in between. E.g., my old (now defunct, so don't bother trying it) Compuserve account password, "knife:other". On Mac OS X, this reduces to "knife:ot" which is easy to remember but hashes to something pretty difficult to crack by brute force.
--Paul
Curriculum Developer
Technical Training and Certification [apple.com]
Apple Computer
Re:Think different -- a better way to do it (Score:2)
My PowerBook G4 has 26 letters, 10 numbers, and 11 other characters I can type, for a total of 47. With the shift key, that's 94. Even if we charitably assume a strong password, 94^8 combinations is only 6.1e15, which is slightly worse than 53 bits of entropy.
So by putting the password in the keychain, even if it is a good one (and quite often it is not), we are left with a disk image which is less protected than conventional, weak 56-bit DES encryption.
Re:Think different -- a better way to do it (Score:2)
Re:Think different -- a better way to do it (Score:1)
Re:Think different -- a better way to do it (Score:1)
Leave it to Microsoft to "extend" the concept of a home directory.
I haven't run into any other installers that use/create a ~/Applications directory, but you never know...
Re:Think different -- a better way to do it (Score:1)
Re:Think different -- a better way to do it (Score:1)
Re:Think different -- a better way to do it (Score:2)
Leave it to Slashdotters to "extend" Microsoft-bashing into realms in which it has no business. ~/Applications is one of OS X's standard application directories, as well as
Encrypted disk image access speed (Score:5, Informative)
--Paul
Re:Linux related questions.... (Score:1)
Re:Linux related questions.... (Score:1)
I want a completely OSS solution to mounting disk images so that I can use my linux scripts on my mac and not have to use Disk Copy.
Re:Linux related questions.... (Score:1)
Nice hack (Score:1)
That's a nice hack indeed. Now let us look at a better solution from NetBSD (only in -current at this stage, will be part of 1.7/2.0, whichever it ends up being called):
http://netbsd.gw.com/cgi-bin/man-cgi/man?cgd+4+Net BSD-current [gw.com].
and the config utility:
http://netbsd.gw.com/cgi-bin/man-cgi?cgdconfig+8+N etBSD-current [gw.com]
Corrupted Disks (Score:1)
Although the disk image will be completely secure if you can't get any files off of it...
Command line access (Score:1)
For example if I ssh into my home machine I get an error:
hdid -passphrase "mysecret" somediscimage.dmg
hdid: mounting somediscimage.dmg" failed: no mountable file systems.
This disc image works just fine if I do the same exact thing while logged in locally.
Re:Command line access (Score:1)
If you are logged in remotely and there is no one on the console, you need to issue the following command:
disktool -c
before using "hdid" to mount the disk image.
Alternatively, you could use "hdid -nomount" and then manually mount the appropriate