You are not logged in.

#1 2012-05-26 02:54:12

Xyne
Moderator/TU
Registered: 2008-08-03
Posts: 5,810
Website

eCryptfs vs EncFS for subdirectories of $HOME

I've used EncFS for a while now to encrypt sensitive files. I find it very convenient to have a stacked filesystem that can grow as needed (as opposed to pre-allocated block encryption).  The encrypted files are not accessed very often so the directory is usually not mounted. Even when it is, IO is not intensive so the performance hit from using FUSE has not been an issue.

Nevertheless, I like the idea of using eCryptfs as it is supposedly faster and seemingly enjoys more widespread support. Additionally, if I've understood it correctly, the metadata is stored in the files themselves instead of EncFS's per-directory configuration file (.encfs6.xml). The files can therefore be decrypted as long as they exist, whereas EncFS files depend on an extra file that could be lost (unlikely with proper backups, but still possible).

The problem with eCryptfs seems to be that it requires either root or fstab entries (which in turn require root). I haven't found a convenient way yet to let a user mount an arbitrary directory at an arbitrary location (arbitrary in the sense that the user has the required permissions). I basically just want to be able to use eCryptfs the same way I can use EncFS.

From what I've read so far it seems that it should be possible with PAM, but I haven't dealt with PAM before so I don't know. I've found guides for setting up encrypted home directories on login, and for setting up fixed mounts (~/.Private and Private), but not for the arbitrary use described above.

Can someone with eCryptfs and/or PAM experience point me in the right direction or tell me if it's impossible? Maybe there's even a simpler way than PAM.





Related question: can encrypted mountpoints be hidden from mtab? Obviously I have pretty big problems if someone has root or physical access to the machine, but I would prefer not to broadcast the location of encrypted directories and when they are mounted.

Offline

#2 2012-05-26 05:10:59

/dev/zero
Member
From: Melbourne, Australia
Registered: 2011-10-20
Posts: 1,176
Website

Re: eCryptfs vs EncFS for subdirectories of $HOME

Xyne wrote:

The problem with eCryptfs seems to be that it requires either root or fstab entries (which in turn require root). I haven't found a convenient way yet to let a user mount an arbitrary directory at an arbitrary location (arbitrary in the sense that the user has the required permissions). I basically just want to be able to use eCryptfs the same way I can use EncFS.

From what I've read so far it seems that it should be possible with PAM, but I haven't dealt with PAM before so I don't know. I've found guides for setting up encrypted home directories on login, and for setting up fixed mounts (~/.Private and Private), but not for the arbitrary use described above.

Can someone with eCryptfs and/or PAM experience point me in the right direction or tell me if it's impossible? Maybe there's even a simpler way than PAM.

I don't know about impossible, but I couldn't figure out how to set up arbitrary mount points.


Xyne wrote:

Related question: can encrypted mountpoints be hidden from mtab? Obviously I have pretty big problems if someone has root or physical access to the machine, but I would prefer not to broadcast the location of encrypted directories and when they are mounted.

Again, I don't know whether it's possible to conceal mount points from mtab, but I wonder whether it would be sufficient to combine ecryptfs with Luks? Certainly, it's easy (and even desirable) to combine the two.


Linux is NOT Windows | The Rootless Root
Toshiba Satellite i5-3230M 2.6GHz CPUs, 4Gb RAM, ArchLinux, wmii, nVidia GeForce GT 740M.

Offline

#3 2012-05-28 19:46:29

Xyne
Moderator/TU
Registered: 2008-08-03
Posts: 5,810
Website

Re: eCryptfs vs EncFS for subdirectories of $HOME

Thanks for the reply.

In the end I gave up fighting with eCryptfs and the hard-coded paths and decided to just go with EncFS for small directories and LUKS for large ones. Using block encryption is not as versatile (fixed size, complicated backups) but I avoid double-encryption overhead and the hassles of using ecryptfs differently from the developers.

I'm not marking this as solved yet because I still think there's a way to do what I want, but I just can't spend any more time on trying to figure out how.

Last edited by Xyne (2012-05-28 19:46:41)

Offline

#4 2012-05-29 20:06:48

Xyne
Moderator/TU
Registered: 2008-08-03
Posts: 5,810
Website

Re: eCryptfs vs EncFS for subdirectories of $HOME

I ended up writing a utility to do what I want:
ecryptfs-simple project page
forum thread

Offline

#5 2012-05-29 20:18:14

headkase
Member
From: Canada
Registered: 2011-12-06
Posts: 1,601
Website

Re: eCryptfs vs EncFS for subdirectories of $HOME

There is also the issue of meta-data being generated off of your encrypted data into areas of the file-system which are not encrypted.  Things like mlocate.  A attacker may be able to gather the names of the files themselves in a situation like that and even that may not be acceptable to you.  LUKS, full-disk encryption, is a better solution when no data at all is acceptable to leak outside of encrypted areas.


We all make choices, but in the end, our choices make us.

Offline

#6 2012-05-29 20:56:28

Xyne
Moderator/TU
Registered: 2008-08-03
Posts: 5,810
Website

Re: eCryptfs vs EncFS for subdirectories of $HOME

As I understand it, both stacked and block systems are visible when mounted. Anything that stores filenames (e.g. "recently used") will store them in both cases, so there is no difference there. When unmounted, you obviously can't get anything from the block device whereas you can still get approximate size, mtime, etc from the underlying directory of the stacked system (but not names, if they're encrypted). Is that what you're referring to?

I agree that block encryption is the better option for full security, but stacked systems have the advantage of dynamic space allocation and easy backups (e.g. rsync of the underlying files).

Offline

#7 2012-05-29 21:07:20

headkase
Member
From: Canada
Registered: 2011-12-06
Posts: 1,601
Website

Re: eCryptfs vs EncFS for subdirectories of $HOME

mlocate as a security-hole in non-full-disk-encryption is mentioned in the Wiki: Here.

Depending on your configuration there may be similar in nature security holes.  An obvious one would be if your swap partition wasn't encrypted and sensitive information was paged out to it and an attacker had access to your machine at a later time - even when the /home information was not unlocked.


We all make choices, but in the end, our choices make us.

Offline

#8 2012-05-30 00:34:41

Xyne
Moderator/TU
Registered: 2008-08-03
Posts: 5,810
Website

Re: eCryptfs vs EncFS for subdirectories of $HOME

When you say "full-disk-encryption", do you mean full system encryption? In that case, I understand your point.

This thread was really only about getting eCryptfs to behave more like EncFS, but I'll give some more background. I already have full system encryption on the target system (with /tmp as tmpfs and encrypted swap with a throwaway key). That protects data when the system is down, but when it's up it provides no protection whatsoever. Obviously the system files need to be accessible for the system to be usable, but users may have sensitive data that they prefer to make accessible (i.e. mount) only when necessary.

In that case, you can either use an encrypted stacked file system or an encrypted block device. Stacked file systems are easier to work with because of dynamic space requirements and the ability to use standard backup tools on the underlying encrypted files. They do leak some data (approximate file size, modification and access times, attributes, etc) though, and there is extra overhead associated with them compared to a block device, even more if they are stacked on top of an encrypted partition. The user has to weight convenience against security and performance, and it very much depends on expected usage.

As for mlocate, /etc/updatedb.conf can be use to ignore ecryptfs and fuse.encfs so that these files are not tracked. It cannot be used to do the same with mounted block devices.

Incidentally, I have opened a bug report to get ecryptfs and fuse.encfs added to the default PRUNEFS array in updatedb.conf: https://bugs.archlinux.org/task/30068

Offline

#9 2012-05-30 12:53:49

headkase
Member
From: Canada
Registered: 2011-12-06
Posts: 1,601
Website

Re: eCryptfs vs EncFS for subdirectories of $HOME

Yes, I guess I mean full system encryption.  Everything but /boot encrypted and using a device mapper to mount them.  You boot and right after grub you enter your password in the console then it unlocks everything else and finishes booting.


We all make choices, but in the end, our choices make us.

Offline

#10 2012-12-11 23:06:32

dav-archlinux
Member
Registered: 2012-12-11
Posts: 1

Re: eCryptfs vs EncFS for subdirectories of $HOME

FYI, this script enables mounting ecryptfs folders without root access or touching the fstab:

http://paste.ubuntu.com/1426333/

Enjoy..

Offline

#11 2012-12-12 13:14:35

Xyne
Moderator/TU
Registered: 2008-08-03
Posts: 5,810
Website

Re: eCryptfs vs EncFS for subdirectories of $HOME

dav-archlinux wrote:

FYI, this script enables mounting ecryptfs folders without root access or touching the fstab:

http://paste.ubuntu.com/1426333/

Enjoy..

I may have misunderstood how that script works, but I believe that ecryptfs-simple does the same thing more efficiently. (C code using the ecryptfs library vs a lot of Bash subshells and shuffling). Perhaps you could help me to improve ecryptfs-simple if you feel that something is lacking instead of working on a separate script.

Offline

#12 2013-01-18 20:23:28

Redsandro
Member
From: Netherlands
Registered: 2013-01-18
Posts: 3
Website

Re: eCryptfs vs EncFS for subdirectories of $HOME

Do you by any chance also know a simple-ish way to automatically mount an arbitrary (not the preconfigured home) passphrased ecryptfs directory when logging in?
Common stuff works when logging in because the user keyring is unlocked. But ecryptfs wants your passphrase to be in the kernel keyring.

Once you've added the passphrase to the kernel keyring with ecryptfs-add-passphrase --fnek, you can mount/unmount transparently without the passphrase using:

sudo mount -it ecryptfs ~/source/ ~/target/ -o ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_enable_filename_crypto=yes,ecryptfs_sig=[sig],ecryptfs_fnek_sig=[sig]

But the next day (aka after reboot) you have to add the key to the kernel ring all over again, making this unconvenient.

I was looking for a way to make a simple arbitrary ecryptfs less rocketsciency and google redirected me to this topic.

Admittedly, I am using Mint Cinnamon in stead of Arch, but we're all friends here, right? cool

-edit-
I guess in theory I want to store the key in my user keyring, and copy it to the kernel keyring when I log in. Then everything can be automated.

Last edited by Redsandro (2013-01-18 20:50:01)

Offline

#13 2013-01-19 09:57:06

hunterthomson
Member
Registered: 2008-06-22
Posts: 794
Website

Re: eCryptfs vs EncFS for subdirectories of $HOME

You should not use eCryptfs. It is not secure.

Use LUKS/dm-crypt instead and provides the same benefits you are looking for in eCryptfs. EncFS's security is still questionable.

Also, just a reminder that you can add an entry in the sudoers file for cryptsetup. Then use udisks or udisks2 to mount the unencrypted block-device as a normal user.

Or, use Loop-AES which is good.

Last edited by hunterthomson (2013-01-19 10:04:52)


OpenBSD-current Thinkpad X230, i7-3520M, 16GB CL9 Kingston, Samsung 830 256GB
Contributor: linux-grsec

Offline

#14 2013-01-19 13:53:28

Redsandro
Member
From: Netherlands
Registered: 2013-01-18
Posts: 3
Website

Re: eCryptfs vs EncFS for subdirectories of $HOME

Why is eCryptfs not secure? I thought, if so many distro's use it as a default, there's gotta be something to it.
I want to use a long passphrase, that's why I need it in my keychain permanently. The keychain is safely locked away in my encrypted home, which can be physically trusted anyway. What can not be trusted is remote locations and portable storage. Hence the long passphrase.

Anyway, LUKS doesn't provide the benefits I am looking for because it's disk-based.
Looking for:

  • File-based enctyption where I can just copy files on usb/smartphone/email and use them on a different location

  • File-system indendent, so no NTFS/EFS, ZFS or something stored in LUKS, loop or sparse files like TrueCrypt

  • Files not depending on anything (e.g. EncFS needs config files in place)

  • Store my project files encrypted remotely on untrusted sources such as dropbox, ubuntu one, google drive.

    • I was thinking of rsyncing inotified ecryptfs changes to the remote as live backup.

As for the remote storage, I have a server running ownCloud but everyone agrees their remote encryption is very insecure. However, it does support interesting WebDAV support for Google Drive and hopefully soon SkyDrive.

Anyway, I think Xyne is right to want to try to automate using EcryptFS.

Cryptsetup in sudoers is one step in the clever direction, but it still queries the kernel keyring, and I still have to add key/sig on reboot?

Last edited by Redsandro (2013-01-19 13:56:14)

Offline

#15 2013-01-19 17:49:57

Xyne
Moderator/TU
Registered: 2008-08-03
Posts: 5,810
Website

Re: eCryptfs vs EncFS for subdirectories of $HOME

hunterthomson wrote:

You should not use eCryptfs. It is not secure.
EncFS's security is still questionable.

[citation needed]

As for the rest of of your remarks, disk-based vs file-based encryption have different uses and are not interchangeable.


@Redsandro
My understanding of how eCryptfs works is overall superficial (which is also why I am not yet disputing hunterthomson's claims) so I do not know how to do what you have described.

As I understand it, you just want to automate mounting of the encrypted directory locally without the passphrase prompt. The only access barrier then is your account login, in which case you may as well just create a script with the passphrase to add it to the keyring automatically (invoked via your shell profile, for example). If that script is only accessibly by your account and never uploaded to remote storage then it would achieve the same level of security, no?

Offline

#16 2013-01-20 06:19:31

hunterthomson
Member
Registered: 2008-06-22
Posts: 794
Website

Re: eCryptfs vs EncFS for subdirectories of $HOME

Well first of all. Don't take my word for it. Second, dm-crypt is the successor to ecyrptfs; why would you use an old system? LUKS is a major improvement on dm-crypt because it provides key abstraction. What distro still uses ecryptfs? Ubuntu, Fedora, OpenSUSE all use LUKS/dm-crypt now. Anyway, distros use ecryptfs and LUKS/dm-crypt by default because they are in the mainline kernel.

Redsandro wrote:

I want to use a long passphrase, that's why I need it in my keychain permanently. The keychain is safely locked away in my encrypted home, which can be physically trusted anyway. What can not be trusted is remote locations and portable storage. Hence the long passphrase.

If your home partition can be physically trusted then there is no need to encrypt it. Disk encryption only provides physical security. Yes always use a long passphrase and change your passphrase about every month or better.

Redsandro wrote:

File-based enctyption where I can just copy files on usb/smartphone/email and use them on a different location

Yes, however with file-based encryption all the data in leaked as soon as you decrypt the file. You could only decrypt the file to like a ramdisk or tempfs to solve that problem. If you want this then use GPG.

Redsandro wrote:

File-system indendent, so no NTFS/EFS, ZFS or something stored in LUKS, loop or sparse files like TrueCrypt

I don't really understand what you are trying to say here. However, with LUKS/dm-crypt you can make a file, mount it with -o loop and encrypt it. Then create any filesystem you want on it.

Redsandro wrote:

Files not depending on anything (e.g. EncFS needs config files in place)

Again, I am not really sure I know what you want. However, for a cross-platform encryption solution you may want to look into TrueCrypt for block encryption and GPG for file encryption.

Redsandro wrote:

Store my project files encrypted remotely on untrusted sources such as dropbox, ubuntu one, google drive.

Yes you can do this with LUKS/dm-crypt. Just mount a file on a loopback, encrypt it with LUKS/dm-crypt and put that file on DropBox.

Redsandro wrote:

Cryptsetup in sudoers is one step in the clever direction, but it still queries the kernel keyring, and I still have to add key/sig on reboot?

It is not a clever step it is what sudo is for. What kind of security would encryption provide if no key is needed to decrypt it? I think what you may be looking for is a keyfile stored on a USB stick.

https://www.youtube.com/watch?v=MPEKX3WE-VI

Last edited by hunterthomson (2013-01-20 06:20:21)


OpenBSD-current Thinkpad X230, i7-3520M, 16GB CL9 Kingston, Samsung 830 256GB
Contributor: linux-grsec

Offline

#17 2013-01-20 07:05:52

hunterthomson
Member
Registered: 2008-06-22
Posts: 794
Website

Re: eCryptfs vs EncFS for subdirectories of $HOME

Awe, you know what. I confused ecryptfs with cryptoloop. You can create a precomputed hash lookup table for cryptoloop.

Last edited by hunterthomson (2013-01-20 07:07:35)


OpenBSD-current Thinkpad X230, i7-3520M, 16GB CL9 Kingston, Samsung 830 256GB
Contributor: linux-grsec

Offline

#18 2013-01-21 18:57:41

Redsandro
Member
From: Netherlands
Registered: 2013-01-18
Posts: 3
Website

Re: eCryptfs vs EncFS for subdirectories of $HOME

Ecryptfs and dm-crypt have both been part of the mainline kernel since 2.6, and ecryptfs is the default for *Buntu.
Having a container on remote storage is a bad idea and not as versatile. Difficult syncing, partial transfer problems, no taking subsections of a gigabyte project with you.

Anyway, apart from opinions, I take that you have no answer to my question? smile

@Xyne, partially true, but having the key in a file has the extra risk of lacking the protection which a keyring has built-in specifically. A stolen keyring is (at least temporarily) useless. A stolen file containing the key is immediately dangerous.

Offline

Board footer

Powered by FluxBB