ecryptfs team mailing list archive

[Aldo Caruso <313812@xxxxxxxxxxxxxxxxxx>]

More side effects working with encrypted homes:

1) The same side effect explained above between user1 and user2 happens
if user2 is a privileged user and if user2 has his home directory
encrypted.

2) If you have your home encrypted, accessing remotely with ssh is not
possible if you demand using private & public keys (setting
PasswordAuthentication = no in the file /etc/ssh/sshd_config ), because
the sshd daemon has to access ~/.ssh/authorized_keys file in a directory
which is not yet mounted.

IMHO, home directory encryption is still unreliable and it should be
userd with care. In its current state, it only protects after rebooting
the machine ( please tell me if this observation is wrong ), and
consequently only protects from a disk or machine physical theft.

-- 
umount of ecryptfs does not automatically clear the keyring (can be mounted by root later)
https://bugs.launchpad.net/bugs/313812
You received this bug notification because you are a member of eCryptfs,
which is a direct subscriber.

Status in eCryptfs - Enterprise Cryptographic Filesystem: Triaged
Status in “ecryptfs-utils” package in Ubuntu: Confirmed
Status in “ecryptfs-utils” source package in Lucid: Confirmed
Status in “ecryptfs-utils” source package in Maverick: Confirmed
Status in “ecryptfs-utils” source package in Jaunty: Confirmed
Status in “ecryptfs-utils” source package in Karmic: Confirmed
Status in “ecryptfs-utils” package in Fedora: Fix Released

Bug description:
How to reproduce :

1) setup a private directory
2)
sudo -s

cd /

mkdir source

mkdir target

cp ~user/.Private/example.pdf source

file /source/example.pdf
/source/example.pdf: data

mount -t ecryptfs source target
Passphrase: type anything that is not your passphrase or passwords
Select cipher: 
 1) aes: blocksize = 16; min keysize = 16; max keysize = 32 (loaded)
 2) blowfish: blocksize = 16; min keysize = 16; max keysize = 32 (not loaded)
 3) des3_ede: blocksize = 8; min keysize = 24; max keysize = 24 (not loaded)
 4) twofish: blocksize = 16; min keysize = 16; max keysize = 32 (not loaded)
 5) cast6: blocksize = 16; min keysize = 16; max keysize = 32 (not loaded)
 6) cast5: blocksize = 8; min keysize = 5; max keysize = 16 (not loaded)
Selection [aes]: 
Select key bytes: 
 1) 16
 2) 32
 3) 24
Selection [16]: 
Enable plaintext passthrough (y/n) [n]: n
Attempting to mount with the following options:
  ecryptfs_key_bytes=16
  ecryptfs_cipher=aes
  ecryptfs_sig=4c748f746abcc24e
WARNING: Based on the contents of [/root/.ecryptfs/sig-cache.txt],
it looks like you have never mounted with this key 
before. This could mean that you have typed your 
passphrase wrong.

Would you like to proceed with the mount (yes/no)? yes
Would you like to append sig [4c748f746abcc24e] to
[/root/.ecryptfs/sig-cache.txt] 
in order to avoid this warning in the future (yes/no)? no
Not adding sig to user sig cache file; continuing with mount.
Mounted eCryptfs

file /source/example.pdf
/source/example.pdf: PDF document, version 1.4


Now I know that the files are really encrypted (using a wrong passphrase on files copied to another computer makes the file unreadable), but I don't understand how root on my system can mount my files without the correct passphrase... is the passphrase stored somewhere? This is really strange and doesn't give me too much confidence in this technology. Let's hope I overlooked something.