Pass through and multiple passphrases

Asked by AlexGenaud on 2010-06-16

(1) When I write a plain text file directly to an encrypted directory (priv/plain) and mount priv/ onto pub/ with ecryptfs_passthrough=n I do not expect to see pub/plain, but I do (however I can not read it). Have I misunderstood 'passthrough'?

$ echo plain > priv/plain
$ find priv pub -type f
priv/ECRYPTFS_FNEK_ENCRYPTED.FWYHPEg...zsU--
priv/plain

$ sudo mount -t ecryptfs priv pub -o ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_passthrough=n,ecryptfs_enable_filename_crypto=y,no_sig_cache

$ find priv pub -type f
priv/ECRYPTFS_FNEK_ENCRYPTED.FWYHPEg...zsU--
priv/plain
pub/hello
pub/plain

$ cat pub/plain
cat: pub/plain: Input/output error

(2) I have the same experience when I mount on top of the same encrypted directory.

(3) However, if I umount pub/ and write a file to pub/, then mount priv/ on top of pub/ with ecryptfs_passthrough=n, then I will not see the plain text file written. Perhaps this is all that is meant by 'passthrough'.

$ sudo umount pub
$ rm pub/* priv/*
$ echo blah > pub/public_plain
$ sudo mount -t ecryptfs priv pub -o ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_passthrough=n,ecryptfs_enable_filename_crypto=y,no_sig_cache
$ find priv pub -type f

(4) If there is both an encrypted file which when expanded is named hello as well as a plaintext file named pub/hello when pub is not a mount point, then when mounted, pub/hello will be the plain text version of the encrypted file. That seems like the expected behavior regardless of 'passthrough'.

$ sudo umount pub
$ echo plain > pub/hello
$ sudo mount -t encryptfs priv pub
$ echo encrypted > pub/hello
$ cat pub/hello
encrypted
$ sudo umount pub
$ cat pub/hello
plain

(5) What I would really like is the ability to mount an encrypted directory on top of itself. I would like to have weak deniability such that one passphrase will reveal certain (perhaps sensitive) data while a different passphrase will reveal alternate (perhaps insensitive) data. I would like the ability to specify the two different 'passthrough' types demonstrated above (pass from pub to pub or priv to pub (or priv to priv when priv is both the encrypted directory and mount point)).

I'm sure the devil is in the details, but it seems like these and similar use cases could be generalized with an additional passthrough flag: Perhaps encrypted_passthrough (new) and mountpoint_passthrough (old).

Question information

Language:
English Edit question
Status:
Answered
For:
eCryptfs Edit question
Assignee:
No assignee Edit question
Last query:
2010-06-16
Last reply:
2010-06-17
Serge Hallyn (serge-hallyn) said : #1

Your first few experiments focus on 'passthrough=n'. The interesting
case is 'passthrough=y'. If you use that, then unencrypted files in
priv/ will appear unencrypted and readable under pub/.

If files exist under pub/ before priv/ is mounted over it, then under
no circumstances will those files show up while priv/ is overmounted.
That would require union mounting, either using a filesystem such as
aufs or using soon-to-come VFS functionality. It is not an ecryptfs
feature, current or planned.

The functionality you actually seek was meant to be a part of
ecryptfs with the ecryptfs userspace daemon (and implemented as
proof of concepts), but I don't know that it was ever fully implemented
upstream. I think the simplest way for you to do it would be to:

1. create pub/dir1, pub/dir2, pub/dir3, etc. (pick meaningful names)
2. when you want one set of data to show, you can
 mount -t ecryptfs pub/dir1 pub/
   with one passphrase
3. when you want anohter set of data to show,
 umount pub/
 mount -t ecryptfs pub/dir2 pub/
   with a different passphrase

The advantage of that is that files you are trying to deny would
not show up unreadable, but not be visible at all.

I'm hoping that if I'm wrong about ecryptfsd, Tyler will set me straight
here.

AlexGenaud (alexgenaud) said : #2

Hi Serge,

Thanks for the response.

> If you use ['passthrough=y'], then
> unencrypted files in priv/ will appear
> unencrypted and readable under pub/.

Yes, that is an interesting case. Mixing encrypted and plaintext data could be very useful in some cases. Just as isolating encrypted and plaintext data could be useful in other cases, as I hope to show.

I would expect passthrough =y to be the opposite of =n. Whereas =y makes plaintext files visible and readable, I would expect =n to completely hide plaintext files. But that is not the case.

It seems as though plaintext files are seen by ecryptfs as corrupted encrypted files rather than simply unencrypted data to be ignored. Though encryptfs already makes a distinction between encrypted and plaintext files when passthrough=y . I can not imagine a use case in which it is desirable to see plaintext file names but receive an I/O error when the file is read.

$ cat priv/plain
plaintext

$ sudo mount -t ecryptfs priv pub -o ecryptfs_passthrough=y
$ cat pub/plain
plaintext

$ sudo umount pub
$ sudo mount -t ecryptfs priv pub -o ecryptfs_passthrough=n
$ cat pub/plain
cat: pub/plain: Input/output error

> If files exist under pub/ before priv/
> is mounted over it, then under no
> circumstances will those files show up
> while priv/ is overmounted.

Right. That's both intuitive and the behavior of any other fstab-like mount point.

> 1. create pub/dir1, pub/dir2, pub/dir3, etc.
> 2. when you want one set of data to show,
> you can mount -t ecryptfs pub/dir1 pub/
> with one passphrase

That's a pretty cool idea.

However, I was only trying to give examples of the four 'interpretations' of passthrough (y|n & priv|pub) and trying to demonstrate that the behavior did not seem symmetric (to me). Anyway, here's a real-world use-case:

 * Work with plaintext files.
 * Commit encrypted changes into a local repository.
 * Publish the repository publically.

Similarly, we might simply want to synchronize/backup the encrypted data. We do not want the synchronization meta-data encrypted.

We initialize our repository in priv/, thus creating .svn, .hg, .git, or some other .meta directories in the encrypted priv/ directory. The .meta directories are only relevant to the data in priv/ and have no relationship to the mounted pub/ data. Since we can not read the pub/.meta data, there is no reason to see .meta file names. Furthermore, we would make a mess of things if we modified or wrote new (encrypted) data to the pub/.meta directories.

[perhaps "passthrough=n file hiding" is a feature request rather than a question]

Can you help with this problem?

Provide an answer of your own, or ask AlexGenaud for more information if necessary.

To post a message you must log in.