On Wed, 2006-12-20 at 15:03 -0700, Kevin Fenzi wrote: > On Wed, 20 Dec 2006 16:23:38 -0500 > katzj@xxxxxxxxxx (Jeremy Katz) wrote: > > On Wed, 2006-12-20 at 22:20 +0100, Ralf Ertzinger wrote: > > > Dave Jones <davej@xxxxxxxxxx> wrote: > > > > > J1) (possibly not FC7 material) installer support for a few > > > > > popular FUSE filesystems > > > > > > > > Tricky, as the filesystems need to be in the installer image. > > > > What's the use-case for this ? The only one I can think of is for > > > > the fuse crypto stuff, and a better solution for crypto installs > > > > is probably going to be to use e2cryptfs. > > > > > > I'd be happy for working dm-crypt support. The kernel bits work, > > > but I can neither install (sanely) on such a device, and initrd > > > support (for encrypted /) seems to be missing, too. > > > > The problem is that how do you handle this in the initrd? You want to > > be able to prompt a user (in their native language) as well as support > > their native keymap. This could very easily require an X server and a > > lot of fonts and other bits. At which point, exactly what are you > > trying to accomplish? > > > > Encrypting data? Very interesting. > > Encrypting the OS bits that anyone can download? Much less > > interesting, IMHO > > I use a method described by my compatriot Sean at: > > http://www.tummy.com/journals/entries/jafo_20060326_215808 > > It simply uses a small script in /etc/sysconfig/modules/ > (which runs right after udev) that loads the dm_crypt modules, and runs > cyptsetup to prompt the user for the password on boot. This can be a little bit better in terms of having the root filesystem mounted and thus you can use X to be able to prompt in the appropriate language and with the right keymap, but some of your questions below remain _very_ relevant as long as we're talking about encrypting the block devices. > If you have the encrypted volume mounted a boot it means you either > can't have unattended boot, or get things breaking that need to > access /home before it's mounted. If you mount at login time, you get > breakage for things that need /home (like mail delivery or the like if > you send it there). How do you handle multiple users? Remote logins? > Backups? Lost passwords? > > This is not an easy problem to solve, but I think it's very important > to get some mindpower working on it. Having encrypted data is very > nice, especially for the expanding linux laptop market. When we're talking _data_, I really think that an answer along the lines of ecryptfs[1] is a far more compelling answer than per-block device encryption. They're looking at doing encryption below a directory tree. This means that each user can have a separate passphrase (or more generally, token) for decryption and then they can even have ~/MyMoreSecretStuff which doesn't even get unlocked when they login. This also helps for some of the cases like mail delivery as you can specify that a subdir below the homedir that isn't encrypted for mail[2]. > We should probably move this discussion to a more appropriate list, but > I'm not sure what that would be. ;) fedora-devel-list? :) Jeremy [1] http://ecryptfs.sf.net, although the current version doesn't support everything that's really needed to make it compelling [2] Although arguably, you should just not deliver to homedirs in this case/have a dedicated mail server -- Fedora-maintainers mailing list Fedora-maintainers@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers -- Fedora-maintainers-readonly mailing list Fedora-maintainers-readonly@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers-readonly
