ecryptfs-setup-private should create an .ecryptfsrc file

[Dustin Kirkland ]

ecryptfs-setup-private should really create a good ~/.ecryptfsrc and sigs file as part of its setup, like so:

> merkaba:~> cat .ecryptfsrc
> ecryptfs_unlink_sigs
> ecryptfs_sig=[…]
> ecryptfs_fnek_sig=[…]
> ecryptfs_xattr
> ecryptfs_key_bytes=32
> ecryptfs_cipher=aes
> ecryptfs_passthrough=n

[Martin Steigerwald (ms-proact)]

Thanks, Dustin.

One part of my suggestion was to store the configuration of an ecryptfs
filesystem within the encrypted directory[1].

With encfs I can rsync the crypted directory to somewhere else and then just
mount it on the remote machine like I would on my local one. I do not have to
think about copying the ecryptfs configuration as well.

Encfs stores its configuration directly in the encrypted directory like this:

merkaba:~> ls -l /home/.ms2/.encfs5
-rw-r----- 1 root root 241 Mai 19 2008 /home/.ms2/.encfs5

[1] encryption metadata not stored with filesystem on ecryptfs vger kernel org:
http://www.spinics.net/lists/ecryptfs/msg00062.html

[Serge Hallyn (serge-hallyn)]

Quoting MartinSteigerwald (<email address hidden>):
> Thanks, Dustin.
>
> One part of my suggestion was to store the configuration of an ecryptfs
> filesystem within the encrypted directory[1].
>
> With encfs I can rsync the crypted directory to somewhere else and then just
> mount it on the remote machine like I would on my local one. I do not have to
> think about copying the ecryptfs configuration as well.
>
> Encfs stores its configuration directly in the encrypted directory like
> this:
>
> merkaba:~> ls -l /home/.ms2/.encfs5
> -rw-r----- 1 root root 241 Mai 19 2008 /home/.ms2/.encfs5
>
> [1] encryption metadata not stored with filesystem on ecryptfs vger kernel org:
> http://www.spinics.net/lists/ecryptfs/msg00062.html

Overall, the suggestion makes sense, and I like it.

But one neat thing about ecryptfs is that you can do

 mount -t ecryptfs /home/user/.Private/some/sub/dir /mnt

or

 rsync -va /home/user/.Private/dir1 host1:
 rsync -va /home/user/.Private/dir2 host2:

So my concern would just be that people would learn to expect the
config file to always get copied with the dir, which wouldn't happen
in this case.

Not sure enough people use it this way to worry about. Just wanted
to point it out. (Giving people magic means they won't know the
limitations of the magic, and get upset when the magic breaks)

-serge

[Dustin Kirkland  (kirkland)]

Taking a few notes for myself...

I was able to get ecryptfs mounting manually using the following:

# cat /root/.ecryptfsrc
key=passphrase
passphrase_passwd=8fab560fcb7f693f6e1411427c4d11d9
ecryptfs_unlink_sigs
ecryptfs_sig=3d7c87fdd9dd0964
ecryptfs_fnek_sig=e94bb6f9dad673b0
ecryptfs_xattr
ecryptfs_key_bytes=16
ecryptfs_cipher=aes
ecryptfs_passthrough=n

# cat /root/.ecryptfs/sig-cache.txt
3d7c87fdd9dd0964

# ecryptfs-add-passphrase --fnek
Passphrase: 8fab560fcb7f693f6e1411427c4d11d9
Inserted auth tok with sig [3d7c87fdd9dd0964] into the user session keyring
Inserted auth tok with sig [e94bb6f9dad673b0] into the user session keyring

# mount -t ecryptfs /home/.ecryptfs/ubuntu/.Private /mnt
Attempting to mount with the following options:
  ecryptfs_unlink_sigs
  ecryptfs_fnek_sig=e94bb6f9dad673b0
  ecryptfs_xattr_metadata
  ecryptfs_key_bytes=16
  ecryptfs_cipher=aes
  ecryptfs_sig=3d7c87fdd9dd0964
Mounted eCryptfs

And the data can be read/written just fine.

Note that the ecryptfs-add-passphrase --fnek is unfortunately necessary to get the fnek loaded. I suppose we could/should add that logic somewhere.

[Tyler Hicks (tyhicks)]

This is a feature request that isn't getting much attention. I'm knocking the importance down to wishlist so it isn't at the top of our bug reports.

[Marco Gamberoni (gamberoni)]

ecryptfs-setup-private should also add a per-user salt in .ecryptfsrc
   salt=<16 random hex digits>
Beware, anything else than 16 hex digits is silently ignored.

The lack of an .ecryptfsrc with a salt= stanza in the standard eCryptfs configuration set up by ecryptfs-setup-private has a security implication: all installations end up wrapping (encrypting) the mount passphrase with the user login password and the DEFAULT SALT VALUE.
A unique salt value among almost all installations makes them a convenient target for a rainbow table attack on the wrapped-passphrase file.

I read in the 2005 document "eCryptfs: An Enterprise-class Cryptographic Filesystem for Linux by Michael Austin Halcrow" that .ecryptfsrc files were intended as "Apache-like policy definition files", but a quick look at actual source code gives me the impression this is not as things stand.
The path ~/.ecryptfsrc is hard coded in cmd_ln_parser.c, which is inconvenient for the common case of encrypting the whole home directory.
I suggest .ecryptfsrc should reside in /home/.ecryptfs/$LOGNAME/.ecryptfs/ config directory, along with wrapped-passphrase, Private.sig, and other configuration information.
I got here because I am dabbling with a config package to implement mandatory eCryptfs encrypted home for all users of a system, and started looking into how pam_ecryptfs does its job. IMHO, removing the hard coded defaults from ecryptfs-utils and implementing and documenting a configuration file should have higher priority than wishlist.

Moreover, .ecryptfsrc does not look to me as an appropriate place for the salt value. Like in /etc/shadow, the sensible place to store the salt is alongside the hash: in wrapped-passphrase.

[Sylvain (sylvain-pelissier)]

I have noticed that ecryptfs-utils is the default program used by the
Ubuntu distributions for home folder encryption since version 10.04.
In this case, the wrapping key is generated from the user password
using the hash function SHA-512. As mentioned previously, the wrapping
key is hashed with the default fixed salt and stored in the
"wrapped-passphrase" file. What’s interesting with Ubuntu
installations, since the salt is fixed, time-memory trade-off (rainbow
tables, etc.) can apply, as well as bulk dictionary attacks to crack
user passwords of Ubuntu installations when the home folder encryption
is activated.
I think a CVE should be open for this issue. I will work on this bug and
propose a patch soon.

[Sylvain (sylvain-pelissier)]

Solved in revisions 839: http://bazaar.launchpad.net/~ecryptfs/ecryptfs/trunk/revision/839.

[Tyler Hicks (tyhicks)]

Hi Sylvain - Let's not hijack this bug to track the salted password security fix. It was originally about ecryptfs-setup-private creating a .ecryptfs file and had nothing to do with the lack of a random salt. AFAIK, there is no bug opened for the salt issue and I only worked from your report on oss-security.