Re: crypto file system

From: Jonathan Schmitt (jonathan.schmitt_at_informatik.uni-augsburg.de)
Date: 02/23/05

  • Next message: Roberto C. Sanchez: "Re: some virtualization issues/comments (qemu,uml)" 
    To: debian-user@lists.debian.org
Date: Wed, 23 Feb 2005 19:19:00 +0100

    Hello back,...

    > > I'm looking for a cryptographic file system to securely store data on a
    > > server, either via something like an encrypted nfs or via a local mount of
    > > an exported nfs share.

    > Do you want to encrypt files for transport only or do you want to store the
    > file encrypted on your harddisk?
    > (If they are stored encrypted, they are transported encryptet as well, so
    > you don't need to encrypt twice ;)

    Yes, I'm aware of this. There are several possible scenarios and we will
    settle for the best we can get. The least is to get away from nfs itself
    (unencrypted data transfers are a lesser problem than authorization by IP).
    This can be done - I understand - for example by sshfs or by using an
    stunnel.
    We hope to get a little bit more out of encryption. In general cfs does
    exactly what we want, store the data encrypted, if You mount the device, only
    You can read it (no root, no other unit - in contrast to loopback for
    example), but there's the issue with the lacking support for some boxes.

    > Every kernelland approach I know causes difficulties with non-linux boxes.
    > Every userland approach approach causes difficulties with transparent file
    > access.
    > However, there are some VFS-drivers allowing to use userland programs to be
    > a file system driver (captive mode NTFS is the best known example I know),
    > but I didn't use it.

    There are no non-Linux boxes that have to be connected, merely some people who
    won't give up their beloved non-Debian distro, which doesn't come with a cfs
    packages and where cfs source can't be compiled with reasonable effort.

    > > Nfs exported crypto loopback seems to be fine in general, but there is a
    > > difficulty with our backup (file backup, all modified files are saved
    > > every day for 90 days, so a 3GB crypto loop would result in some admins
    > > coming for my head).

    > Well, If you export an encrypted file system r/w on nfs, there is a good
    > changes that is is either screwed-up or non-writeable for most of your
    > users.

    Thanks, that's what I feared.

    > There are many utils for encrypting files,
    > I use gpg for userland only accesses, and loop-aes for kernelland accesses.
    > (loop-aes allows userland access as well).

    Well, as I said, crypto-loop will cause severe difficulties with our current
    backup strategy. I wouldn't want to go through this. GPG is what we currently
    do mainly, that leaves several problems open. You have the plain text file
    stored on Your computer and if You use emacs for editing, You end up with
    those darn ~ files (which are good in general, but bad here), You have to
    remember to clean up.
    So neither crypto loop nor gpg would be sufficient to solve all problems.

    > If you want to use a encrypted file system, you have to know exactly when
    > which data have to be encrypted and it what ways it has to be accessed.
    > Perhaps a ssh tunneld nfs may be enough.

    The ideal solution would be: data encrypted on server, transferred in an
    encrypted way and then decryptet user-readable only on the client. The next
    best solution is something like sshfs or tunneled nfs (which would still
    imply the use of gpg for the more sensitive files).
    By the way, NCryptFS actually is still vaporware, right?

    Best regards,
    Jonathan 

    -- 
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
  • Next message: Roberto C. Sanchez: "Re: some virtualization issues/comments (qemu,uml)"