Bug 812508 - encrypted Private directory mountable with arbitrary password
encrypted Private directory mountable with arbitrary password
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: ecryptfs-utils (Show other bugs)
16
All Linux
unspecified Severity high
: ---
: ---
Assigned To: Michal Hlavinka
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-04-14 03:01 EDT by Freddy Willemsen
Modified: 2012-04-16 10:44 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-04-16 09:28:29 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Freddy Willemsen 2012-04-14 03:01:08 EDT
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 09:28:29 EDT
> 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 10:44:36 EDT
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!

Note You need to log in before you can comment on or make changes to this bug.