7

Is it possible to implement scheme where remote server just share its filesystem (or resizable container file in it) and it's locally encrypted and mounted? And what is best practical method? (On linux.)

Example use is backup storage on not very trusted server.

catpnosis
  • 215
  • 1
  • 8

2 Answers2

7

Sounds like what you're looking for is encfs. It's FUSE layer on top of any existing FS which encrypts and decrypts on-the-fly, storing the encrypted version in the underlying filesystem. The catch is that file metadata (ownership, sizes, times) is visible, but content and names are not.

You can also use --reverse to go the other way around: make an encrypted view of an unencrypted fs -- useful for making rsync-friendly encrypted backups.

EDIT TO ADD
As pointed out by Æsahættr, another usable option is eCryptfs. This is an in-kernel FS driver, which means root permission is required. But it's very low performance overhead and much faster then encfs in my own tests. While the implementation is quite a bit different between the two, the way you use them is nearly identical:

encfs /base_dir/ /view_dir/
# or
mount -t ecryptfs /base_dir/ /view_dir/

By default, encfs scrambles filenames while ecryptfs does not, but these options are configurable. Also, ecryptfs adds much more per-file overhead than encfs does because it stores metadata in the file itself, while encfs stores it in a hidden xml file. Also, the --reverse option that encfs has doesn't really translate well to ecryptfs; ecryptfs has ecryptfs_encrypted_view but it probably won't work the way you expect it to. Supposedly this is a work-in-progress.

Both can use any filesystem as a base; including, for example sshfs. But bear in mind that file ownership and permissions are stored as-is on the base filesystem, which could mean access-denied errors if you don't match things up correctly, or losing permissions completely if you base on a FS that doesn't support them.

tylerl
  • 82,225
  • 25
  • 148
  • 226
  • I only fear that fuse stuff is slow and encfs is not enough crypto audited. But I may be wrong. – catpnosis Nov 06 '12 at 13:31
  • 1
    @catpnosis Fuse is going to be no slower than any other userspace encryption tool. The crypto itself is OpenSSL which you may or may not trust. Encfs has been audited a few times and has been revised because of it. – tylerl Nov 06 '12 at 18:12
  • There's also [ecryptfs](http://ecryptfs.sourceforge.net/ecryptfs-faq.html#compare) which Ubuntu uses for its home directory encryption, etc. This is another stacked file system. I believe it would also work over networks. –  Nov 06 '12 at 22:09
  • Edited to add ecryptfs and associated comparison – tylerl Nov 07 '12 at 18:25
  • @tylerl Thanks for the follow up about eCryptfs! That is interesting. – catpnosis Nov 09 '12 at 02:18
  • 1
    @ tylerl @Æsahættr From the hint in [ecryptfs FAQ](http://bazaar.launchpad.net/~ecryptfs/ecryptfs/trunk/view/head:/doc/ecryptfs-faq.html) and this [ticket](https://bugs.launchpad.net/ecryptfs/+bug/277578) - *ecryptfs will not work properly* in networked scenario (over NFS for example) as requested in my question. Alas. – catpnosis Nov 09 '12 at 11:25
  • @catpnosis It seems that encfs is still an option, as would be a reverse-encryption mount option. `ecryptfs_encrypted_view` works under certain circumstances, so that may be worth pursuing. But it's not as simple as you might hope it would be. – tylerl Nov 09 '12 at 17:59
3

Yes, if you want to use encrypted container file, you can access the remote filesystem using NFS, CIFS or SSHFS protocols. For remote access to a block device you can use iSCSI, NBD or AoE. Personally, I'd benchmark access over CIFS and NFS with an encrypted container file and then use the one that is the fastest for me.

Matrix
  • 3,988
  • 14
  • 25