Booting to an Encrypted Root Partition
I am attempting to boot a Linode with an encrypted root partition.
I have done this successfully on local virtual machines, but wanted to set one up on Linode.
My difficulty is with booting the system on the encrypted partition, not in setting up the encrypted partition or encrypted system.
From my understanding, I need to use the "pv-grub-x86_64" kernel in the Linode manager.
I consulted this forum post in which someone seemed to be doing something similar (
I have the Linode disks configured as such:
/dev/xvda /boot
/dev/xvdb swap
/dev/xvdc encrypted root partition
My /etc/crypttab is setup as follows:
crypt-xvdc UUID=myuuid none luks
My /etc/fstab is setup as follows:
prox /proc proc nodev,noexec,nosuid 0 0
/dev/mapper/crypt-xvdc / ext3 errors=remount-ro 0 1
/dev/xvda /boot ext3 defaults 0 2
/dev/xvdb swap swap defaults 0 0
I edited the /boot/grub/menu.lst file as in the Linode How To.
After update-grub, the file contains the following:
title Ubuntu 12.04 LTS, kernel 3.2.0-23-generic
root (hd0)
kernel /vmlinuz-3.2.0-23-generic root=/dev/xvdc console=hvc0 ro quiet quiet splash
initrd /initrd.img-3.2.0-23-generic
title Ubuntu 12.04 LTS, kernel 3.2.0-23-generic (recovery mode)
root (hd0)
kernel /vmlinuz-3.2.0-23-generic root=/dev/xvdc console=hvc0 ro quiet single
initrd /initrd.img-3.2.0-23-generic
When I attempt to boot the following set in the Linode Manager:
Kernel: pv-grub-x86_64
Xenify Distro: off
Root device: /dev/xvda
I invariable get dropped at a "grubdom" prompt.
Attempting to manually type in the same grub commands as above (at the console) results in a password prompt for decrypting the disk (yay!), but then errors out afterwards:
Output
grubdom> boot
close blk: backend at /local/domain/0/backend/vbd/3376/51712
close blk: backend at /local/domain/0/backend/vbd/3376/51728
close blk: backend at /local/domain/0/backend/vbd/3376/51744
Unlocking the disk /dev/disk/by-uuid/myuuid (crypt-xvdc)
Enter passphrase: ********
cryptsetup: crypt-xvdc set up successfully
mount: mounting /dev/xvdc on /root failed: No such device
mount: mounting /dev on /root/dev failed: No such file or directory
mount: mounting /sys on /root/sys failed: No such file or directory
mount: mounting /proc on /root/proc failed: No such file or directory
Target filesystem doesn't have requested /sbin/init.
No init found. Try passing init= bootarg.
BusyBox v1.18.5 (Ubuntu 1:1.18.5-1ubuntu4) built-in shell (ash)
Enter 'help' for a list of built-in commands.
Questions:
Is what I'm trying to do possible? (Encrypted root partition on a Linode), or am I just wasting my time?
Any suggestions for where to look for more information?
Any suggestions to fix the current problem with boot using grub?
Thanks!
11 Replies
how did you generate the initrd? I'm wondering if that's wrong?
mount: mounting /dev/xvdc on /root failed: No such device
should that be /dev/mapper/crypt-xvdc?
My primary errors involved the boot parameters for grub.
The initrd itself was fine – installing the kernel after having setup cryptsetup with /etc/crypttab seems to have run the necessary hooks to include the correct modules.
While I have not managed to set everything up to my satisfaction yet (due to fiddling on my part), I have been able to boot the system.
I found the following wiki page from Arch Linux to be extremely helpful:
My grub menu.lst now contains:
title Ubuntu 12.04 LTS, kernel 3.2.0-23-generic
root (hd0)
kernel /vmlinuz-3.2.0-23-generic root=/dev/mapper/crypt-xvdc cryptdevice=/dev/xvdc:crypt-xvdc console=hvc0 ro splash
initrd /initrd.img-3.2.0-23-generic
title Ubuntu 12.04 LTS, kernel 3.2.0-23-generic (recovery mode)
root (hd0)
kernel /vmlinuz-3.2.0-23-generic root=/dev/mapper/crypt-xvdc cryptdevice=/dev/xvdc:crypt-xvdc console=hvc0 ro single
initrd /initrd.img-3.2.0-23-generic
Once I have a good list of steps for how I set everything up, I'll be sure to include them.
@kuleszaj:
Once I have a good list of steps for how I set everything up, I'll be sure to include them.
I'd be interested in seeing them. From what I've seen on other systems the slowdown caused by disk encryption should not even be noticeable.
one gotchas, making the initrd in the chroot in finnix didn't set up crypt properly, even though /etc/crpytab was correct, it was finding some other file with incorrect info on it. I've seen that before at home. I fixed it by booting and failing to mount /, then type the commands in manually at the busybox prompt to mount / and once booted regenerate initrd again and reboot.
I did mine a bit differently to kuleszaj, I have two linode disk images /boot (ext3) and crypt (raw) on the cyrpt image I use lvm to make / and swap.
kuleszaj, are you going to recreate and encrypt your swap with a random key every boot? or what?
now what happens when I reboot is I have to log into lish, and i see the regular boot messages and a luks password prompt, I put my password in and it continues to boot, mounting / and doing everything else as normal.
with FDE, you can't use linodes backups, i never used them anyway, so no loss for me. and you can't shrink a raw partition, but everything else works, including growing the raw disk image, migrating, and etc.
Hopefully this will be useful for someone.
As awesome as this is, it seems only like an exercise.. .
if you get into my linode web account, and like, no one has ever cracked a web app before, you can't reset my linode root password, all you can do is shut it down.
if you don't think this is important, someone did exactly that to steal 100s of k worth of bitcoins from some linodes a year or two back.
@redrs:
I can not fathom what the practical benefits of having an encrypted Linode would be? Seems to add nothing but unnecessary complexity. You're not gaining any security.
As awesome as this is, it seems only like an exercise.. .
There are security improvements:
Anyone that gains Dashboard access can't get your data, they can only trash things.
Nobody with physical access to the host can steal one of the mirrored disks and get your data. These machines are in shared data centers so lots of people might be able to get physical access to them.
The US government can't easily get hold of all your data. On shared hosting they might have a legitimate reason to suspect someone on the same host as you or they might go crazy and take entire racks. It's happened before.
A rouge Linode admin could not get hold of your data. At least not easily.
If you keep email on your Linode there are likely passwords in it and enough information to borrow your identity. SASL keeps passwords in plain text if you use MD5 based authentication, and even the system password hashes are useful if they are crackable and reused elsewhere.
What's to stop LISH being mitm'd to capture your password?
@redrs:
If the machine is running then the drives have been decrypted, yes? How can you guarantee no one has copied data off your disk while the VM is running?
Because it doesn't store the unencrypted version on disk that would be tricky, but technically possible with full access to the hardware and enough time.
@redrs:
What's to stop LISH being mitm'd to capture your password?
You have to trust LISH and your local keyboard have not already been setup to capture your passphrase. You could use that same argument about ATMs but they still used everywhere.
Encrypting filesystems prevents quite a lot of attack vectors. You can't claim it's not worthwhile because it doesn't cover all possible attacks. Nothing covers all possible attacks.