Bug 812508

Summary: encrypted Private directory mountable with arbitrary password
Product: [Fedora] Fedora Reporter: Freddy Willemsen <freddy>
Component: ecryptfs-utilsAssignee: Michal Hlavinka <mhlavink>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 16CC: esandeen, mhlavink
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-04-16 13:28:29 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Freddy Willemsen 2012-04-14 07:01:08 UTC
Description of problem:
I have used ecryptfs-setup-private script to create an encrypted dir. So far so good. However, using this sequence of commands (executed as a regular user) allow me to mount and use the encrypted Private dir with an arbitrary password (even just a dot suffices):

sudo chmod 4755 /sbin/mount.ecryptfs*
[ ! -e /sys/fs/ecryptfs/version ] && modinfo ecryptfs >/dev/null 2>&1 && /sbin/mount.ecryptfs_private --loadmodule
/sbin/mount.ecryptfs $HOME/.Private $HOME/Private -o user,key=passphrase,no_sig_cache,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_passthrough=n,ecryptfs_unlink_sigs,ecryptfs_enable_filename_crypto=n


Version-Release number of selected component (if applicable):
ecryptfs-utils-96-1.fc16.x86_64
kernel-3.3.1-5.fc16.x86_64

How reproducible:
Always

Steps to Reproduce:
1. ecryptfs-setup-private
2. logout/login
3. sudo chmod 4755 /sbin/mount.ecryptfs* (only needed for regular user)
[ ! -e /sys/fs/ecryptfs/version ] && modinfo ecryptfs >/dev/null 2>&1 && /sbin/mount.ecryptfs_private --loadmodule
/sbin/mount.ecryptfs $HOME/.Private $HOME/Private -o user,key=passphrase,no_sig_cache,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_passthrough=n,ecryptfs_unlink_sigs,ecryptfs_enable_filename_crypto=n
  
Actual results:
The passphrase is ignored and the Private dir is mounted and usable

Expected results:
The passphrase is checked and if incorrect the Private dir will not be mounted

Additional info:

Comment 1 Michal Hlavinka 2012-04-16 13:28:29 UTC
> sudo chmod 4755 /sbin/mount.ecryptfs*

Why are you doing this? This is not how it's supposed to work.

> 1. ecryptfs-setup-private
> 2. logout/login

there is login automount feature, it should be mounted right now (if you use ordinary authentication mechanism) and encryption key is in the keyring

once key is in the keyring, it can be mounted with just mount.ecryptfs_private

I've used 'etest' user when following your steps, so lets verify it:
$ mount | grep Private
/home/etest/.Private on /home/etest/Private type ecryptfs (rw,relatime,ecryptfs_fnek_sig=35a62ff6f25f78d0,ecryptfs_sig=d474f8008663cbbd,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_unlink_sigs)

lets test it:
echo "Hello world" >Private/sayhello.txt

> 3. /sbin/mount.ecryptfs $HOME/.Private $HOME/Private -o
user,key=passphrase,no_sig_cache,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_passthrough=n,ecryptfs_unlink_sigs,ecryptfs_enable_filename_crypto=n

what you did right now is that you mounted Private directory with new key

$ mount | grep Private
/home/etest/.Private on /home/etest/Private type ecryptfs (rw,relatime,ecryptfs_fnek_sig=35a62ff6f25f78d0,ecryptfs_sig=d474f8008663cbbd,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_unlink_sigs)
/home/etest/.Private on /home/etest/Private type ecryptfs (rw,relatime,ecryptfs_sig=87d04721f6b4fff1,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_unlink_sigs)

ls Private/
ECRYPTFS_FNEK_ENCRYPTED.FWYpdWzqwZxso-R7EvlpgchL1f.6wX.6jwFEVu2duUcrWJ3ICNMDYC70dE--

as you see ^^^ that sayhello.txt file have no longer readable name, because last mount turned file name encryption off.

cat Private/ECRYPTFS_FNEK_ENCRYPTED.FWYpdWzqwZxso-R7EvlpgchL1f.6wX.6jwFEVu2duUcrWJ3ICNMDYC70dE--
Hello world

but you can still read it, ecryptfs in kernel has both keys available

echo "HELLO WORLD" >Private/sayhello2.txt

ecryptfs-umount-private

mount | /home/etest/.Private on /home/etest/Private type ecryptfs (rw,relatime,ecryptfs_fnek_sig=35a62ff6f25f78d0,ecryptfs_sig=d474f8008663cbbd,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_unlink_sigs)

ls Private/
sayhello2.txt  sayhello.txt

we have file name encryption turned on again

ecryptfs-umount-private

Private/ contains just README as usual, data available only in .Private and they are encrypted

logout/login

ls Private
sayhello2.txt  sayhello.txt

sayhello.txt is Hello world, sayhello2.txt is garbage, well would be, you'll get "input/output error", because kernel does not have key to decrypt this file.

so

> Actual results:
> The passphrase is ignored and the Private dir is mounted and usable

this is wrong. You are mounting it with different key, explicitly bypassing key checks (by calling mount directly instead of ecryptfs-mount-private) and you get your files encrypted with the password you've entered. If you use different password next time, they won't be readable. Don't try to do dark magic with ecryptfs-utils or you will lose your data.

Comment 2 Freddy Willemsen 2012-04-16 14:44:36 UTC
Bollocks, pardon my ignorance. I actually forgot one crucial step in my own experiment, which I did describe but not actually do: logout/login (or better yet, rebooting). After this,, it is indeed impossible to read the original data.

Quite right, this is not a bug. I will sleep a lot happier!