Re: partially encrypted filesystem

[Valdis . Kletnieks]

On Wed, 03 Dec 2003 13:07:56 PST, Kallol Biswas <kbiswas@xxxxxxxxxxxx>  said:
>       We have a requirement that a filesystem has to support
> encryption based on some policy. The filesystem also should be able 
> to store data in non-encrypted form. A search on web shows a few 
> encrypted filesystems like "Crypto" from Suse Linux, but we need a
> system  where encryption will be a choice per file. We have a hardware
> controller to apply encryption algorithm. If a filesystem provides hooks
> to use a hardware controller to do the encryption work then the cpu can
> be freed from doing the extra work.
> 
> Any comment on this?

1) Key management will be a royal pain in the posterior, especially if more
than one key is in use on the filesystem (either at the same time, or at
different times).

2) Encryption of files is not all it's cracked up to be, security-wise.  In
particular, it only really guards against an attacker who gets access to the
data while the key isn't accessible (in other words, it does NOT protect
against your root user, or against any trojan horse or other attack that reads
the files while they're accessible in a decrypted form).  You will probably
drive the user bonkers if they have to enter the key at each open() call,
unless you're in a high-enough security model that making it that difficult for
the legitimate user is called for, in which case...

3) Only encrypting some files means an *incredible* amount of data leakage -
even without the file data, you're leaking the file name (unless the directory
is also encrypted), and all the inode data.  That's data an attacker can use -
knowing that an "interesting" file is more than a megabyte in size, has a
filename that's 17 chars long, and was modified yesterday may be enough to tell
them something crucial.

4) Remember information leakage to /tmp and the like - it's pointless to use
crypto on a file that gets vi'ed and puts a copy in a plaintext /tmp for
recovery once the laptop gets stolen. ;)  Better bets here are using tmpfs for /
tmp (and encrypted swap on a loopback so if it DOES hit the disk it's not
useful).

All in all, you're probably better off just using PGP to encrypt individual
files, or an encrypted loopback.   Note that the following *will* work if you
don't want to burn a whole partition per user:

mkdir /crypto
mkdir /crypto/${USER}
chown ${USER} /crypto/${USER}

mkdir ~user/.crypto
dd if=/dev/zero of=~user/.crypto/diskfile bz=1M count=20
losetup -e AES ~user/.crypt/diskfile
mkfs /dev/loop/0

After that, 'mount -o loop,ecryption=aes ~user/crypto/diskfile /crypto/${USER}'
will do it.

(I've probably glossed over a bunch of utii-linux version dependencies - the exact details
are different between the 2.12 and 2.11+loop-aes-patch versions)

Amazingly enough, if you need more space, you can just unmount it, use something
like 'dd if=/dev/zero >> disfkile' to increase it, losetup it, fsck it, resize2fs it,
and remount it....

This is done with already-existing standard tools, and fulfills the requirement
(just put only the crucial files in there).  You can even use symlinks to
redirect (for instance) ~/.important into the encrypted space.

Writing stuff like a Gnome prompter for use at login is left as an excersize
for the reader ;)

Attachment: pgp00001.pgp
Description: PGP signature