Archive for linux

FIX: Ubuntu usplash stops “Waiting for resume device”

I am currently messing with Ubuntu 9.04 on my laptop, and as usual I’ve set up an encrypted root filesystem and an encrypted swap; this time I preferred to use the distributions built-in means for disk encryption (basically dm-crypt and LUKS). It worked like a charm, you just have to use the Alternate CD in order to have the disk encryption options available.

There was only a minor glitch: the usplash graphical boot stopped right after the message “Waiting for resume device” leaving me with the plain old text boot; the solution is written in this bug report. The proposed patch from Florent Mertens will not work for Ubuntu 9.04 but it contains everything you need to fix the problem: you just have to edit the file /usr/share/initramfs-tools/scripts/local-premount replacing the line

/sbin/usplash_write "TIMEOUT ${slumber}" || true

with

/sbin/usplash_write "TIMEOUT $(( ${slumber} + 2 ))" || true

Basically usplash stops itself if there isn’t anything written on the standard output after a certain time; since the “Waiting for resume device” operation takes too much time this modification adjusts the timeout accordingly.

Always on the bug report there is a possible explaination for this behaviour: on the last post Alexander Sashanov says that one of the way to reproduce this bug is to change the swap partition’s UUID. Since my swap device is encrypted with a random key and so mkswap is executed at every boot, the swap UUID changes indeed at every boot, causing the timeout.

Leave a Comment

Still tinkering with Loop-AES

Thanks to my new Toshiba Satellite A300 capabilities, from some months now I changed my Loop-AES setup to use a USB memory stick as boot device instead of the old CD-ROM. I also found a nice distribution as rescue system, System Rescue CD, which supports most of my laptop’s hardware and has built-in support for Loop-AES.

Configuring Loop-AES for USB boot was pretty straightforward, thanks to the README; I just had to adjust a parameter for the build-initrd.sh script, namely INITIALDELAY=8, in order to give my system enough time to recognize the USB device right after the kernel is loaded.

For some time I had two USB memory sticks: one to boot my laptop, the other one with System Rescue CD. An idea came to my mind: why not merge their content in the same USB drive? If I do that, then I can use only one drive both to boot my laptop and to boot the rescue system; the other drive can be a backup of this one, for safety reasons.

This turned out to be pretty easy: I’ve copied SysRescueCD files to the USB drive used to boot the computer following the instructions of the manual, I’ve changed a bit SysRescueCD’s syslinux.cfg to add Loop-AES’ boot instructions and finally  I’ve removed Loop-AES’ syslinux.cfg. The modifications to SysRescueCD’s syslinux.cfg looks like this:

default linux
...
label linux
 kernel vmlinuz
 append initrd=initrd.gz root=100 init=/linuxrc rootfstype=minix
...

In the end it was all about changing the default clause and adding Loop-AES boot configuration. Actually I modified syslinux.cfg a bit more, to add a custom boot picture, set the default keyboard map to match my Italian layout and things like these, but I’ll keep that out for simplicity.

Leave a Comment

System Rescue CD

I’ve been looking for quite some time for a live CD that supported Loop-AES in order to do some system maintainance on my laptop; Knoppix does a very good job at that, but unluckly it doesn’t have a recent kernel. As result, with Knoppix I could mount easily my encrypted root partition but I was unable to use both my wireless and ethernet network cards.

When I was about losing hope to have something ready and I almost started building a custom Knoppix with a recent kernel (or a custom Slax, patched with Loop-AES support) I found a wonderful Live CD that has everything I need: System Rescue CD.

The distribution's logo

The distribution's logo

The last x86 version features a 2.6.27.10 kernel and full Loop-AES support. I just tested it and it works flawlessy: I can mount my Loop-AES encrypted root partition and use my ethernet and wireless network cards while running this live distribution from an USB pen-drive!

I still havn’t explored the tools available on the Live CD/USB but it looks like having a rather interesting feature list. The distribution itself is based on Gentoo Linux.

Kudos to the System Rescue CD authors… They really did a cool job! :-D

Comments (1)

Disk encryption: an example with Loop-AES

This post’s topic is exactly the same as a speech that I did at the MOCA 2008. I enjoy using encrypted disks from several years and I think it is a topic worth writing about. The first part of this post will be an introduction about disk encryption in general; an overview about a particular setup for laptops’ hard disks will follow.

Why you should bother about encrypting your disks? The exact goal here is to protect the confidentiality of your data when it is not being used. This means that you should not worry about other people accessing your files if your laptop is stolen, or if you lose a CD-ROM or a USB memory key. On the other hand, if an opponent accesses your encrypted disks while you’re using them disk encryption will be bypassed. Also, disk encryption alone doesn’t grant data integrity and availability.

So, is it worth to spend time and effort into encrypting your disks after all? As usual, when taking decisions about security, you have to make a trade-off: if you encrypt your disks you’re not likely to put at danger 25 million people’s personal data just by losing a CD-ROM, for example. Nowadays we can store a lot of data in very little space: think about CD-ROMs, USB memory keys… even laptops keep getting smaller. The smaller the storage device, the easier is to lose it or to have it stolen.

I am going to describe my laptop’s disk encryption setup as a practical example of what disk encryption involves. My laptop runs Linux (Arch Linux, to be precise) and it has only one hard disk. To implement disk encryption I’ve used Loop-AES; it was the best choice for the setup I wanted to do and I think this still holds true. Loop-AES has a very well made README: everything I will describe can be seen there in detail, command by command and updated to the last Loop-AES version. For this very reason my description won’t be detailed: if you want to do this setup, or one of the others described in the Loop-AES README, check it out; if you’re Italian you may also want to look at the translation of the README’s sections that involve this particular setup.

In general, when encrypting a disk the more data you encrypt the better it is. Most of Linux full disk encryption setup that I found on the Internet are not really full. They leave out the /boot partition because the boot loader, be it LILO or Grub, is not able to boot the system using a kernel from an encrypted /boot partition. Keeping your /boot partition unencrypted makes it relatively easy for it to be tampered with and this could have bad consequences for the rest of the encrypted disk too. Even if I said before that disk encryption does not assure data’s integrity I think that it is better to avoid leaving /boot unencrypted. Being this paranoid, I’m not even going to consider encryption schemes that involves only home directories for the same reason and, moreover, because sensitive data can be written on other disk places as well: think of /var or /tmp as examples.

My setup involves two partitions on the hard disk: the root and the swap partition, both encrypted using the AES cipher with 256 bit keys. I assume that the target system has a working Linux installation with that partition scheme.

The first step is to install Loop-AES itself. Loop-AES has a kernel space part, which just replaces the standard kernel module for loopback devices management, loop.ko. The user space tools required to use Loop-AES are modified versions of some util-linux programs: mount, umount, swapon, swapoff and losetup. In order to realize the full disk encryption with a boot CD-ROM, diet-libc and statically compiled versions of GPG, and AESpipe are also needed. The latter is an utility downloadable from the Loop-AES website that can encrypt the data that it reads from the standard input.

The swap partition is simply encrypted with a random key generated at every computer’s boot. After having installed Loop-AES this means just a little modification on /etc/fstab. Using a random encryption key at every boot means that that at every reboot the data previously written on the swap partition is lost. This is not a problem for me because I don’t use suspend-to-disk.

The root partition setup instead is more articulated: the unencrypted /boot partition resides on a CD-ROM that I bring along with me even when I don’t have my laptop at hand.

To create the boot CD-ROM you need to have a kernel with some custom options set : as example, you don’t want to compile the loopback device driver on it, neither built-in nor as module, because Loop-AES replaces it. Then you will need a key file, created with GPG; Loop-AES will use your password to unlock this key file and the 65 keys that are on it to encrypt the disk; this implies that an opponent without the keyfile (that is on the boot CD-ROM) will have to crack all the 65 keys to get your data. An initial RAM-disk is also needed: in the Loop-AES distribution there is a script that creates it accordingly with a configuration specified by you. Last, to have your boot CD-ROM working, you will need to put a boot loader on it: the README suggests using ISOLINUX that indeed works very well (I had fun customizing its startup picture).

The last step is to encrypt the data of your root partition. In order to do this you need to reboot your system with a Live-CD or something alike, modify the /etc/fstab root partition entry and use the AESpipe utility to actually encrypt your disk’s content. This will take quite some time (at least it did on my old laptop), but after this your work is really done!

Comments (1)