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
