Isn't it time for the encrypted file system???

[David Zeuthen]

On Sat, 2006-03-25 at 10:38 -0500, Christopher Blizzard wrote:
> David Zeuthen wrote:
> > (btw, for FC6 and GNOME 2.16 I hope to have a very simple formatting /
> > partitioning tool for drives which will include setting up LUKS
> > partitions - and it won't do silly things like requiring the root
> > password (in the default install; will be configurable) for at least
> > removable and hotpluggable media. Of course I can't promise to have this
> > done for FC6 as I presently do most of this in my spare time...)
> 
> Is there any chance that we can come up with something that doesn't 
> require something that's block-level and requires repartitioning?  The 
> migration path pretty much sucks if we don't try for something else.

I think Jeremy's point about using block level encryption on real disks
for anything but removable / hotplugable devices makes sense. I also
don't think we want to encrypt the entire home directory, that would
suck for e.g. compiles of software

Filevault on Mac OS X is also interesting

 http://www.apple.com/macosx/features/filevault/

So.. I've been toying with the idea of just using a loopback mount on
$HOME/Documents;

 - The crypto bits are just store in $HOME/.encrypted-documents-image

 - Loopback mount said file on /dev/loop5 (or whatever)

 - when logging in, setup crypto using cryptsetup so the clear image
   is /dev/mapper/foo

 - if there is no fs on /dev/mapper/foo (/sbin/volume_id can tell us)
   format /dev/mapper/foo to be an ext3 file system

 - Mount /dev/mapper/foo at $HOME/Documents on login

 - Teach the file chooser / Nautilus about it
   - emblems
   - patch file chooser to warn if saving outside $HOME/Documents,
     maybe apps can set a property on the FileChooser object to
     disable this warning

 - Might want to move and symlink .gconf, .gnome2, .gnome2_private,
   whatever into $HOME/Documents

Issues

 - Will probably require a system-level D-BUS service to do the heavy
   lifting; that's fine; D-BUS is the way to allow privileged operations
   to desktop processes in a secure way. And with the glib bindings it's
   not too difficult to do...

 - Not sure how to make the image grow when running out of space; maybe
   that requires some kernel bits; kernel guys?

 - Issues on NFS / shared homedir - but this is true on any attempt to
   do encrypted homedir

 - Issues with data migration if user already has something in 
   $HOME/Documents - maybe just move it to the new encrypted target

 - Clearly this (and any attempt to do encrypted home directories) needs
   Single Sign On so we can recover the encryption key easily when the
   user authorizes as part of the login process - it's equivalent to our
   desire of unlocking the GNOME keyring, see

    https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=125682

   for details.

It's all about trade-off's I think ; I'm not sure we can please everyone
but I think this is a good compromise. 

So.. if you are crazy you may even use the same technique of of loopback
mounting the image on $HOME but I don't think it's acceptable to encrypt
the entire home directory. Or maybe it is... It really depends on what
we want to do... Maybe some user interaction guys like clarkbw or seth
should sit down and work out what user experience we want before we
discuss technical implementation details... 

Anyho.. before we can do anything we also need to solve bug #125682.. I
think many people will agree with me that it's annoying enough as is
with having to manually unlock the keyring everytime one wants to use
VPN or mount encrypted removable storage :-)

    David