[clug] SSH Public key auth + Encrypted home dir

[Daniel Pittman]

steve jenkin <sjenkin at canb.auug.org.au> writes:
> Michael Cohen wrote on 25/8/09 10:29 PM:
>
>> I have never really understood the advantage that per user crypted home dir
>> give you.

Yeah, me either.  The only option I can see is that it can protect you from
casually revealed data to other users.

>> It seems that the threat model is to prevent one user from reading another
>> user's encrypted files, but this is normally enforced by system
>> permissions.

*nod*  I will note, though, that my experience is that many, perhaps even
most, Linux users these days don't seem to have a good mental model of these
permissions.  It could be that people just don't /know/ that this protection
exists, so encrypted home directories look more attractive.

[...]

> Is it to protect against super-user accessing your files?
>
> Plus you've never said how you enter the passphrase on login, before the
> home directory is mounted.
>
> If it doesn't ask, then root can presumably 'su -' and get the files.

Nah, the PAM stack prompts and uses the password.  So, root or root-equivalent
users can just instrument the PAM stack and capture the password on the way
through and all.

> If you leave the directory mounted ('screen') then root will be able to
> just read any file, won't they?

Yes.

> The only advantage it seems to give is protecting backups/files copied
> off-line.

Pretty much, as far as I can see.  I certainly see disk encryption as more
valuable against realistic threat models.


However, I think a large part of the motivation for Ubuntu using the eCryptfs
model is *not* security, but rather performance:

Using per-user directory tree encryption without needing a block device
allocated you can:

1. Avoid the performance cost of encrypting anything outside that tree.
   - this includes /*/{lib,usr}, which can make a difference on low power
     systems
   - this also avoids the penalty for users who don't opt in to encryption
2. Avoid the need to allocate block devices, either through loopback sparse
   files or real block storage.

Both of those are real advantages, and might be compelling enough for Ubuntu.

Now, I wonder if my hypothesis is right?

http://lmgtfy.com/?q=ubuntu+blueprint+encrypted+home+directory

...which leads to...

https://wiki.ubuntu.com/EncryptedPrivateDirectory
https://blueprints.launchpad.net/ubuntu/+spec/server-karmic-encrypted-home-offered-to-all-users

(Tsk, tsk.  They didn't fill out the second blueprint properly.)

Not too bad: I missed a couple of their points, even if their arguments are
not totally true:

3. Encrypted block devices requires a passphrase at system restart.
   (Actually, only to access the device in question, which for /home can be
    delayed, but that would be much more complex and require something other
    than the default cryptsetup configuration.)

4. All content is encrypted with a single passphrase.

5. Incremental backups of encrypted data are impossible with whole-device
   encryption, but are possible with the eCryptfs model
   - on the flip-side, eCryptfs leaks file boundaries, and possibly file
     names, as a consequence of enabling this.


So, there you go.

Regards,
        Daniel
-- 
✣ Daniel Pittman            ✉ daniel at rimspace.net            ☎ +61 401 155 707
               ♽ made with 100 percent post-consumer electrons
   Looking for work?  Love Perl?  In Melbourne, Australia?  We are hiring.