
Ubuntu's Encrypted Home Directory: A Canonical Approach to Data Privacy - linuxmag
http://www.linux-mag.com/id/7568
======
dguido
I hate to be trendy when it comes to security, but home directory encryption
makes "Evil Maid"-type attacks much easier. If I have 5 minutes with your
laptop, I can replace/backdoor any system binaries you rely on and give the
device back to you. It's much safer to encrypt everything, even after you know
that someone crazy like Joanna can come by and backdoor your MBR.
[http://theinvisiblethings.blogspot.com/2009/10/evil-maid-
goe...](http://theinvisiblethings.blogspot.com/2009/10/evil-maid-goes-after-
truecrypt.html)

~~~
silentbicycle
One downside of encrypting _everything_ is that you're providing attackers
with a very large body of known plaintext.

~~~
jrockway
One upside of spending millions of dollars on cryptography research is that
this is unlikely to help even the most able of your adversaries.

Also, the NSA does not really want to see your porn stash. They captured it as
it was being downloaded.

------
btilly
The biggest gotcha that I see is restoring backups. According to the article,
for that you need to have the actual long passphrase used internally, and not
your regular password. So when you're in trouble you need to come up with a
critical piece of information that you never use and probably don't know.
That's going to bite more than a few people at a bad time.

Otherwise it looks excellent.

~~~
aceofspades19
Another gotcha would be that it would be difficult to rescue since the ubuntu
livecd doesn't have that app by default and I don't know of any livecds that
do

~~~
nuclear_eclipse
If the live disc doesn't have that "app", then how can it possibly set up home
directory encryption during the installation process?

~~~
aceofspades19
I saw that they used apt to install it, so I would imagine that it doesn't
have it installed by default. Also not all livecds would have it so you would
have to depend on the ubuntu livecd

------
pyre
Somehow this was enabled on my Jaunty install at work. Things I found out a
couple of days ago (when I ran into probs):

* Ssh keys have caveats with this setup.

* You need to login at least once (locally,ssh,etc) because it needs your system password to mount the ecryptfs on your home directory. So you can still use the benefits of ssh keys if you need to login to the same machine with the same user account multiple times. You'll just need to use the system password the first time.

* If you only need to access something outside of your encrypted home, you _can_ created a ~/.ssh directory in the unmounted home directory and cat your public key there. (Your login will have have an empty home directory unless you manually mount eCryptFS)

* Because the mounting can happen in a PAM module, this is leaps and bounds ahead of Apple (at least a couple of years ago). My experience with FileVault was that you needed to login through the GUI to get a mounted home directory. SSH logins were a no go (except for an empty home dir).

------
dstorrs
They compare this to OSX FileVault in the article, so I thought I'd share
this: I've been explicitly told by an Apple-approved technician that they
don't recommend FileVault. The process of dynamically resizing the encrypted
partition on the fly leads to a higher number of filesystem errors, many of
which are non-recoverable.

~~~
mseebach
_The eCryptfs layered file system approach also eliminates the need for a
dedicated partition, sparse file, or preallocated disk space for the encrypted
data. eCryptfs files are written to the administrator’s chosen underlying file
system with the total disk capacity available. Since each encrypted file is
written to disk as an atomic unit, users can perform per-file incremental
encrypted backups to remote storage – something that is impractical and
dangerous with block device encryption solutions._

