Linux as a bootloader? Encrypted LVM2 rootfs + kernel?

Guenther Brunthaler · Apprentice Joined: 22 Jul 2006 Posts: 217 Location: Vienna

Hi all,

when studying the complexity and power of certain bootloaders such as GRUB which understand filesystems, allow editing and viewing of files etc, I wonder why not also next logical step on the "boostrap adventure game" was taken yet:

Why not using a fully-blown Linux kernel itself as a second-stage bootloader?

I think it must be possible somehow to achieve this: loadlin does a very similar job, only from within a running DOS. So why should the same not also be possible from within a running Linux? And I know there is a kexec system call, allowing to replace a running kernel by another one much in the same way an exec can replace an executable by a different one within a running process.

I know, it's just a weird idea and I have not yet any idea how to actually make all that work as intended, but read on if you are the adventurous type of person!

The possibility to "boot Linux from Linux" should then allow a boot sequence like the following:

Precondition 1: There are only 2 partitions on your hard disk. The first partition is as small as possible (depends on logical HDD geometry and partition scheme used, but will typically be 8 or 16 MB). This partition contains nothing else than a Linux kernel image with an included ramfs or an initrd image.
Precondition 2: The rest of the harddisk is one big partition, completely encrypted using truecrypt or LUKS. Inside that encrypted container (when decypting it), a hard disk image can be found, which consists of one big LVM2 partition. This will prevent any bad guy who stole your notebook to figure out your actual partition layout.
Precondition 3: Within that encrypted LVM2 partition, there are all the partitions (as LVM2 locical volumes) one actually wants to work with, incuding the root filesystem partition, and also a /boot partition.
Precondition 4: The /boot partition (inside its encrypted container) contains the actual Linux kernel to be used for the installation. Which means it is also encrypted and makes it impossible for an attacker to easily modify it (such as adding a keylogger to the kernel to spy out your passwords).
When actually starting the boot sequence, the Linux image on the first (unencrypted) disk partition is booted first. This can be a rather stripped-down version of the kernel, because it needs no drivers for most of the hardware devices except keyboard, console and block-level hard disk access. If you are using an initramfs image instead of an initrd image, you will not even need a filesystem driver. (See the "early userspace" document in the Linux kernel Documentation subdirectory for more details.)
As the last stage of the first Linux kernel's boot process, it will decompress the contents of its embedded initramfs cpio-archive into a RAM-based root filesystem, and transfer control to the /init script it finds there, or to /linux in the case of the initrd method. I'll assume the initramfs method for the rest of this posting.
This script loads any necessary keymap, opens a VT console and prompts the user for a password.
Then it passes that password to truecrypt/LUKs, which will in turn provide a block device in /dev/mapper/, which will decrypt the contents of the second hard disk partition on the fly when accessing it, basically turning it into a virtual decrypted hard disk.
Now the script must initialize LVM2, allowing access to the logical LVM2 volumes on that virtual disk.
It now has access to the /boot partition on the LVM2 volume also.
The script must then somehow manage to load the kernel image from that /boot partition into a RAM-buffer which has been allocated in a way which allows co-operation with the kexec system call. If this is only a single image file, it may not even be necessary to use a filesystem on /boot. Just open the contents of /boot as a .gz or .zip or .bz2 "file" directly from the block device, and extract what's inside. But of course a filesystem can also be used if you prefer.
Now the password required for decrypting the encrypted disk must be added to the kernel image in its RAM buffer in a way which allows the second kernel to extract that information later.
Next, the encrypted disk, LVM2 and any filesystems that might have been mounted must be unmounted/shut down/remounted readonly.
As the last action of its life, our first-stage /init script now must trigger a kexec kernel call, transferring control to the second kernel in its RAM buffer.
Now the second stage Linux kernel image, originating from the encrypted LVM2 /boot partition, begins its own boot sequence. This is the actual kernel we want to be using. It will typically also be a more up-to-date version than the stage 1 kernel. The stage 1 kernel will not be updated very often (if ever). And as the stage 1 kernel will never be used to do networking or other potentially dangerous tasks, there is also no need to update it regularly. Its only job is to finally launch the second stage kernel. It doesn't matter whether it may be buggy in some other respect. It will only have a a very short lifetime (= while it is running).
The second stage Linux will also contain an initramfs image and an /init script, passing control to it.
This second stage /init script must now somehow extract the password which has been attached to the second stage kernel in-RAM image by the first stage /init script.
Then it should pass that password to its own copy of truecrypt/LUKS in order to mount the encrypted second hard disk partition again as a virtual decrypted hard disk.
After doing that, the /init script must be sure to wipe the password from RAM, so nobody will be able to find it there by examining /proc/kcore or by similar methods.
/init must then initialize LVM2 and mount the intended root file system of the installation as a read-only filesystem from its logical LVM2 volume.
As its last step, /init must erase any files in the current RAM based root filesystem, including itself, and do a chroot to the mounted root file system for the installation, exec'ing /sbin/init there.
/sbin/init will then do the remaining system initializations as usual. However, the RC scripts must be somehow tweaked to not reinitialize the disk encryption or LVM2 driver in a way which renders the mounted LVM2 root filesystem unusable.

So, that's what I want!

I know that it's crazy, mad, absolutely nuts, pure science fiction and that no one ever has made anything like that before. (At least from what I've heard so far.)

But - wouldn't it be nice to have such as system?

As stated at the beginning of my posting, my knowledge about Gentoo and Linux in general is not deep enough yet to implement this on my own.

But perhaps one of you, reading this, can contribute useful ideas how to actually implement a system like (or at least similar to) the one described.

So, let's just discuss it!

And finally, here are some more thoughts about the issue:

Having an LVM2 root filesystem is extremely useful. As LVM2 volumes can be resized on the fly, you need not know how to partition your system in advance.
For instance, it may be clear from Gentoo experience that it might be a good idea to use a separate partition for /var/tmp. And another one for the swap file. But what about smaller "/"-subdirectory trees like /var, /opt, /usr or /usr/share? Should they also go into separate partitions, or remain part of "/"? And how large should they be made?
If the rootfs is an LVM2 volume, it will be all easy to change this. You can shrink or enlarge "/", add or remove partitions; just as you like.
If "/" is on a conventional partition with a fixed size, you are screwed in such cases, and it may take a complete backup, repartitioning, and full restore to adapt the partition layout to changed storage requirements.
Having an encrypted kernel also has several advantages: As it will be loaded from an encrypted volume, you can trust it to a much higher degree to not have been tampered with since you installed it there.
Data integrity. Disk encryption will usually render the contents of a complete disk cluster completely unusable if only a single bit of the original (encrypted) disk cluster was flipped. Which means you will notice it when you try to use the data. There is no chance that only a single digit in your spreadsheet or C source code file will subtly be changed into another character, going by unnoticed with possible catastrophic consequences.
If an attacker still wants to get your password, his only chance is to modify the stage 1 kernel, because everything else is encrypted. However, this stage 1 kernel has only a very limited lifetime: It will soon be replaced by the stage 2 kernel, which cannot directly be modified by the attacker.
The stage 1 kernel is also a minimal kernel only, not providing an IP stack or any other means for the attacker to communicate any captured password via a network connection.
Of course, the attacker could replace the stage 1 kernel with a modifed version which includes an IP stack. But the very restricted size requirements of the stage 1 kernel in its small partition will make this at least difficult.
But in order to be sure, the first partition can be removed completely from the hard disk, moving it onto some external storage medium, such as an USB memory stick or a bootable CD. As long as you always remove that boot medium after successful booting (and take it with you when you go away from your notebook), no-one who steals your notebook will be happy with the contents of your hard drive.
Or the first (stage 1 linux) partition may remain on the hard disk, but its contents will be encrypted as well. Your USB/CDROM boot medium will then only need to contain a primitive real-mode BIOS-based boot loader, which hooks INT13 and its LBA extensions, providing on-the-fly decryption of the encrypted partition which contains the stage1 kernel. Then control can directly be transferred to some boot loader on the encrypted partition, being itself encrypted. As decryption is transparent due to the hooked INT13 driver, the Linux loader will be able to load the encrypted stage 1 kernel without any additional modifications. The INT13 hook code from your USB stick may even use a constant, hard-coded decryption key, because the attacker won't have access to the USB stick anyway. Also, the stage1 kernel will still prompt for the actual password to use, so the stage 1 decryption password is not too security-critical. This approach may be interesting to you if your USB stick has only a very limited capacity (is too small to contain a compressed linux kernel image on its own).
Or a combined method can be used: The USB stick contains the kernel image and an initramfs, but this initramfs image is only very minimal: It just contains a single, statically linked /init executable which prompts for a password. (This will eliminate the need for a shell or shared libraries.) It does not contain any device mapper or LVM2 or truecrypt/LUKS disk drivers. These have been compiled as modules, but the driver files are not part of the initramfs image. Then the statically-linked executable uses the password to decrypt the contents of the first hard disk partition on the fly, using its own compiled-in decryption routines, and populates the initramfs with the decrypted files extracted from the first hard disk partition. Those extracted files will include the kernel modules required for supporting device mapper, disk encryption etc. It also contains any required shell (such as ash or busybox), helper binaries and all the required shared libraries, as well as the actual initialization script for doing the remaining setup. This way the actual kernel image including its initramfs can be very small, as the rest of the required binaries will be read from the encrypted first partition on the hard disk.
As a modification of the above scheme, it is also possible to skip the password query and use a hard-coded password from within the scripts instead. Considering your USB stick to be a "key" then, it's not actually necessary to prompt the user for a password. But I am far from recommending this method generally, as even keys can get stolen.

MrUlterior · Guru Joined: 22 Mar 2005 Posts: 511 Location: Switzerland

Frankly I don't see the advantage of your two kernel approach, it sounds like an overly complex method to achieve something that is already quite common: full disk encryption.

I presently boot my workstation off a business card CD that goes with me everywhere. This CD contains;

grub
my full kernel
root.gpg
gnupg statically compiled
gentoo 2006.1 minimal livecd (for use in rescue/repair)

Basically when I boot, loop-aes prompts me for a password to decrypt "root.gpg" (gnupg convential encryption) which is the key for the RAID1 which makes my / - this is ciphered with aes256, once the root FS is mounted & pivot_root executed, it then compares the SHA1 sums stored on / against the contents of the boot CD. Checksum failure results in immediate poweroff _BEFORE_ net.eth0 and net.eth1 are started or /home is mounted. If the checksum's pass, it then starts crypto-loop which will mount all the other partitions using keys from /etc/keys and the boot continues as normal.

In the event that the CD is compromised, all I have to do is re-encrypt / (only 1gb) the larger partitions keys are not contained on the boot cd therefore they can remain. Additionally even if a potential attackers has the CD, they still need a the passphrase to decrypt the keys it contains. Physical access to the PC is now secure as it's unbootable without the CD and the harddrives contain no cleartext at all ...

Am I missing some vital function that the 2 kernel approach would provide?
_________________

Misanthropy 2.0 - enough hate to go around

batistuta · Veteran Joined: 29 Jul 2005 Posts: 1384 Location: Aachen

Whichever approach you guys decide that is the easiest, I would like to learn more about it.
MrUlterior, you say that you have already implemented this. However, your description is not enough for a newbee in encryption to get the thing working. I know it's a lot of work, but if you manage to write a tutorial or how-to on this I'm sure a lot of people will benefit from this. I know people looking for a solution like you are describing, but I haven't found any decent beginners tutorial. However, full disc encryption is something that even beginers need to do sometimes (by beginners I mean Gentoo beginers, to Win beginers :wink:

)

If on the other hand you've learned this from some already published site, I would really apprecite some link. I like your approach, I would only change Gentoo LiveCD with System rescue since Gentoo Live doesn't support reiser4
Thanks!

MrUlterior · Guru Joined: 22 Mar 2005 Posts: 511 Location: Switzerland

Guenther Brunthaler · Apprentice Joined: 22 Jul 2006 Posts: 217 Location: Vienna

batistuta · Veteran Joined: 29 Jul 2005 Posts: 1384 Location: Aachen

Thanks very muc MrUlterior for your tips and links, I really appreciate and I will certainly look into that.

I'm sorry Guenther for having diverged a bit from your topic. Your approach also sounds like it could have its place in some more complex systems. I will start with MrUlterior's approach in order to learn a bit on the subject and follow your progress as well.

My only suggestion, is that whatever you guys do then gets documented, I've found very time consuming and frustrating experience to use HD encryption, due to the fragmentation of docs in the net, or outdated material. It's just impossible to get the thing working without a deep understanding of many things and reading tons of docs. And even then (I've read a lot, believe me), it's hard to get it done. I know some people who even sticked to XP because of encryption easyiness...

So please document what you guys do, tons of people will appreciate it.

MrUlterior · Guru Joined: 22 Mar 2005 Posts: 511 Location: Switzerland

batistuta · Veteran Joined: 29 Jul 2005 Posts: 1384 Location: Aachen

MrUlterior · Guru Joined: 22 Mar 2005 Posts: 511 Location: Switzerland

Voltago · Posted: Mon Sep 11, 2006 3:17 pm Post subject:

Just when you think you had a really clever idea, you can rest assured it will turn out someone had it before you

http://kboot.sourceforge.net/

MrUlterior · Guru Joined: 22 Mar 2005 Posts: 511 Location: Switzerland

Guenther Brunthaler · Apprentice Joined: 22 Jul 2006 Posts: 217 Location: Vienna

Guenther Brunthaler · Apprentice Joined: 22 Jul 2006 Posts: 217 Location: Vienna