Disk encryption support in Etch

Well, I got my new MacBook Pro 15″ in yesterday. I’ll write something about that shortly. The main OS for this machine is not Mac OS X, though, but Debian.

I decided that, being a laptop, I would like to run dm-crypt on here. Much to my delight, the etch installers support dm-crypt out of the box.

Not only that, but they supported this setup out of the box, too:

  • Two partitions for Debian — one for /boot, everything else on the second one
  • The second partition is completely encrypted
  • Inside the encrypted container is an LVM physical volume
  • Inside the LVM physical volume are logical volumes for /, /home, /usr, /var, and swap
  • XFS is used for each filesystem

Not only that, but it set up proper boot sequence for all of this out of the box, too.

So I turn on the unit, enter the password for the encrypted partition, and then the system continues booting.

Nice. Very nice.

Kudos to the debian-installer and initramfs teams.

5 thoughts on “Disk encryption support in Etch

  1. Is XFS such a good idea for a battery based system? Granted you’ve probably got some great battery longevity when it’s new, but XFS on a battery would freak me out.

  2. Indeed, the installer is very very nice in this regard. However, you should probably also encrypt your /boot as otherwise it could be tampered with (e.g. replacing your kernel with one that does hidden keylogging or something). I’m currently trying to set up something like this using kexec; basically you have a small initrd which contains cryptsetup, lvm tools and kexec (+kexec kernel support). In that initrd you decrypt the disk (cryptsetup luksOpen), vgchange -ay, mount /boot (which is on the encrypted partition), load the kernel+initrd there via kexec (kexec -l), umount, vgchange -an, cryptsetup luksClose, kexec -e. That starts the kernel on your encrypted /boot which then asks you for the passphrase etc.

    That [i]should[/i] work, but it doesn’t currently; I need to debug this…

    Alternatively, you can put /boot on a read-only medium such as a CD-R, but that’s a bit inconvenient — you need to create a new CD-R after each kernel upgrade.

    HTH, Uwe.

  3. I don’t know that XFS particularly better or worse than ext3. ext2 is probably the ultimate in tunability for a laptop, but that comes at the cost of drastically raised fsck times and lower reliability.

    As for an encrypted /boot, yes that is a point, but your small initrd setup is no better — you still have an unencrypted initrd. The booting from CD-R isn’t a silver bullet, either — someone could just swap your CD-R (or USB key or whatever).

    My main goal was to prevent data compromise if the laptop is stolen, so dm-crypt I think will do that well.

  4. Well, yes, it all depends on your goals and on your level of paranoia, I guess :)

    A CD-R is fine in that it’s not writable. You can (physically) sign the CD-R with a non-removable ink or mark it through some other means, so that you can detect if it’s really the one you think it is… Doing that should be enough to secure it from malicious manipulations. That system will not be the weakest link in your security anyways, an attacker would probably try to use easier attack vectors (social engineering, exploiting your network daemons, holes in your firewall, whatever)…

    Uwe.

  5. [quote]However, you should probably also encrypt your /boot as otherwise it could be tampered with (e.g. replacing your kernel with one that does hidden keylogging or something).[/quote]

    Just have tripwire check the /boot partition and it will notice wether there is tempering.

    Greetings Rob

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.