ecryptfs-setup-private should create an .ecryptfsrc file
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
| eCryptfs |
Wishlist
|
Dustin Kirkland |
Bug Description
ecryptfs-
> merkaba:~> cat .ecryptfsrc
> ecryptfs_
> ecryptfs_sig=[…]
> ecryptfs_
> ecryptfs_xattr
> ecryptfs_
> ecryptfs_cipher=aes
> ecryptfs_
Changed in ecryptfs: | |
status: | New → Triaged |
importance: | Undecided → High |
assignee: | nobody → Dustin Kirkland (kirkland) |
Martin Steigerwald (ms-proact) wrote : | #1 |
Serge Hallyn (serge-hallyn) wrote : Re: [Bug 906550] Re: ecryptfs-setup-private should create an .ecryptfsrc file | #2 |
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://
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/
or
rsync -va /home/user/
rsync -va /home/user/
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) wrote : | #3 |
Taking a few notes for myself...
I was able to get ecryptfs mounting manually using the following:
# cat /root/.ecryptfsrc
key=passphrase
passphrase_
ecryptfs_
ecryptfs_
ecryptfs_
ecryptfs_xattr
ecryptfs_
ecryptfs_cipher=aes
ecryptfs_
# cat /root/.
3d7c87fdd9dd0964
# ecryptfs-
Passphrase: 8fab560fcb7f693
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/.
Attempting to mount with the following options:
ecryptfs_
ecryptfs_
ecryptfs_
ecryptfs_
ecryptfs_
ecryptfs_
Mounted eCryptfs
And the data can be read/written just fine.
Note that the ecryptfs-
Tyler Hicks (tyhicks) wrote : | #4 |
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.
Changed in ecryptfs: | |
importance: | High → Wishlist |
Marco Gamberoni (gamberoni) wrote : | #5 |
ecryptfs-
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-
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/.
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) wrote : | #6 |
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-
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) wrote : | #7 |
Solved in revisions 839: http://
Tyler Hicks (tyhicks) wrote : | #8 |
Hi Sylvain - Let's not hijack this bug to track the salted password security fix. It was originally about ecryptfs-
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: www.spinics. net/lists/ ecryptfs/ msg00062. html
http://