Encrypt Your Root Filesystem
This key will be copied to the Flash disk later.
4) Create a dm-crypt device, encrypted using the key you just generated:
# cryptsetup -d /etc/root-key create root /dev/hda4
Accessing /dev/mapper/root now provides an encrypted layer on top of /dev/hda4. By default, cryptsetup creates an AES-encrypted dm-crypt device and assumes a keyspace of 256 bits.
5) Create an ext3 filesystem on /dev/mapper/root:
# mkfs.ext3 /dev/mapper/root
6) Mount the new filesystem:
# mkdir /mnt/encroot # mount /dev/mapper/root /mnt/encroot
7) Now that you have an encrypted filesystem, you must populate it with the contents of /dev/hda5 (the original root filesystem):
# cp -ax / /mnt/encroot
8) Finally, create an entry in /mnt/encroot/etc/crypttab so that various utilities know how the filesystem was configured:
root /dev/hda4 /etc/root-key cipher=aes
Now that we have our encrypted filesystem ready, it is necessary to understand a little more about the target architecture's boot process. Generally, computers have firmware that hands off execution to the software that will complete the system boot. Protecting firmware is beyond the scope of this article, so we assume that the system's firmware can be trusted. Most readers probably are familiar with the BIOS, the boot firmware used by the PC platform. I focus on Open Firmware, a boot system used by computer manufacturers such as Apple, Sun and IBM.
The installation instructions for NetBSD/macppc provide a good introduction to Open Firmware. We are interested in using Open Firmware's command-line interface to configure the computer to boot from a removable Flash disk. Open Firmware allows you to view the devices connected to a computer and view and set the value of firmware variables.
The Open Firmware prompt can be accessed by holding down option-command-o-f on a New World (G3 and later) Apple computer during the initial boot process.
The variable boot-device is used to determine what device the system should use to boot. The printenv command allows one to inspect its current value:
> printenv [...] boot-device hd:,\\:txbi hd:,\\:txbi
This essentially means “boot by executing the file of HFS type txbi on the first IDE disk.” The second : character (before txbi) causes the token to be interpreted as an HFS file type. Otherwise, txbi would be interpreted as the path to a file. In my case, the token hd is actually an alias to the more complicated /pci@f4000000/ata-6@d/disk@0. This string represents the path through various subsystems to the first IDE disk. You can see what device an alias resolves to using Open Firmware's devalias command.
To set the boot-device correctly we need to discover by what name Open Firmware knows our Flash disk. Examining the device tree printed by the ls command reveals the path to the Flash disk:
> dev / ls [...] /pci@f2000000 [...] /usb@1b,1 [...] /disk@1 [...]
Now that we know a little bit about the firmware's view of the computer, we must spend some time investigating the software the firmware initially executes: the bootloader. Generally, Linux systems that run on Apple's PowerPC architecture employ a program called yaboot to boot the system. yaboot is similar to LILO or GRUB and contains two key programs, ofboot.b and yaboot. ofboot.b provides the first stage of the bootstrap process. Essentially, it is ofboot.b's job to determine what operating system to boot. For example, if a system has both Mac OS X and Linux installed, ofboot.b executes Mac OS X or Linux's bootloader. If the user chooses to load Linux, ofboot.b executes yaboot, the second stage of the bootstrap process. yaboot then loads the Linux kernel and, in our case, an initrd. Figure 3 provides a illustration of how Linux boots using an encrypted root filesystem on the PowerPC architecture.
Our removable boot device requires the ofboot.b and yaboot programs, a Linux kernel and an initrd that contains the encryption key. Apple's current PowerPC-based architecture expects its boot media formatted using HFS.
1) Use the parted program to create the proper bootable partition on the Flash disk (mine is 64MB and is accessed using the device node /dev/sda):
# parted /dev/sda (parted) mklabel mac (parted) print Disk geometry for /dev/sda: 0.000-62.500 megabytes Disk label type: mac Minor Start End Filesystem Name Flags 1 0.000 0.031 Apple (parted) mkpart primary hfs 0.031 62.500 (parted) print Disk geometry for /dev/sda: 0.000-62.500 megabytes Disk label type: mac Minor Start End Filesystem Name Flags 1 0.000 0.031 Apple 2 0.031 62.500 untitled (parted) set 2 boot on (parted) name 2 Apple_Boot (parted) quit
2) Create an HFS on the boot partition:
# hformat /dev/sda2
3) Configure yaboot to boot off the appropriate device by modifying /mnt/encroot/etc/yaboot.conf. The following is a minimum configuration:
boot=/dev/sda2
ofboot=/pci@f2000000/usb@1b,1/disk@1:2
partition=2
install=/usr/lib/yaboot/yaboot
magicboot=/usr/lib/yaboot/ofboot
default=linux
image=/vmlinux
label=linux
root=/dev/hda4
initrd=/initrd.gz
read-only
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Sponsored by AMD
Built-in forensics, incident response, and security with Red Hat Enterprise Linux 6
Every security policy provides guidance and requirements for ensuring adequate protection of information and data, as well as high-level technical and administrative security requirements for a system in a given environment. Traditionally, providing security for a system focuses on the confidentiality of the information on it. However, protecting the data integrity and system and data availability is just as important. For example, when processing United States intelligence information, there are three attributes that require protection: confidentiality, integrity, and availability.
Learn more about catching the bad guy in this free white paper.
Sponsored by DLT Solutions
| Dynamic DNS—an Object Lesson in Problem Solving | May 21, 2013 |
| Using Salt Stack and Vagrant for Drupal Development | May 20, 2013 |
| Making Linux and Android Get Along (It's Not as Hard as It Sounds) | May 16, 2013 |
| Drupal Is a Framework: Why Everyone Needs to Understand This | May 15, 2013 |
| Home, My Backup Data Center | May 13, 2013 |
| Non-Linux FOSS: Seashore | May 10, 2013 |
- RSS Feeds
- Dynamic DNS—an Object Lesson in Problem Solving
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Using Salt Stack and Vagrant for Drupal Development
- New Products
- A Topic for Discussion - Open Source Feature-Richness?
- Drupal Is a Framework: Why Everyone Needs to Understand This
- Validate an E-Mail Address with PHP, the Right Way
- What's the tweeting protocol?
- Tech Tip: Really Simple HTTP Server with Python
- Kernel Problem
1 min 13 sec ago - BASH script to log IPs on public web server
4 hours 28 min ago - DynDNS
8 hours 4 min ago - Reply to comment | Linux Journal
8 hours 36 min ago - All the articles you talked
11 hours 1 sec ago - All the articles you talked
11 hours 3 min ago - All the articles you talked
11 hours 4 min ago - myip
15 hours 29 min ago - Keeping track of IP address
17 hours 20 min ago - Roll your own dynamic dns
22 hours 33 min ago
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?





Comments
Point Made!
"This scenario may be a bit far-fetched, but it does illustrate a point."
Actually, the point it illustrated for me was that you have the right mindset and understanding to be writing such an article. Until I got to this point I was highly skeptical ;- )
Randomizing a disk: 'shred' from GNU Coreutils.
I would recommend using 'shred' from the GNU Coreutils package to create random noise on a disk. As an alternative, use the standalone package 'wipe'.
I've played with various ways of overwriting disks, including "dd if=/dev/urandom of=/dev/XXXX", "openssl -in /dev/zero -out /dev/XXXX", etc., and I discovered the tools designed for securely overwriting disks are much faster at it. The man pages describe their algorithms and link to papers on the methodologies. 'shred' is nice, since it's on nearly every Linux box by default.
For example, to overwrite SATA disk 0 partition 2:
shred -vn 1 /dev/sda2
Application to Intel PC architectures
I successfully extrapolated your instructions to an Intel architecture PC with only minor changes required.
**Preparing the USB Flash Disk
I prepared the USB Flash disk by formatting it as FAT16 and using syslinux (http://syslinux.zytor.com/) to install the bootstrap program. This works cleanly to boot most PC's built in recent years. It may be necessary to go into the BIOS and add USB to the list of boot options, depending on how your PC is setup.
**Modifying mkinitrd
I downloaded the latest source for mkinitrd (4.2.03) and applied the patch that you specified in your article. The patch had been updated since your article, so the flag -authtype=paranoid is no longer required: mkinitrd now automatically looks for /etc/crypttab to determine the authtype setting.
I had to edit a line in /sbin/mkinitrd to make it work. The original line that runs cryptsetup is as follows in mkinitrd (line 787 for 4.2.03):
echo "cryptsetup $cryptsetup_params -d /root-key create root /dev/root" >> $RCFILE
I had to change /dev/root to /dev/hdxx, consistent with the entry in /etc/crypttab:
echo "cryptsetup $cryptsetup_params -d /root-key create root /dev/hda6" >>$RCFILE
(In my case /dev/hda6 is the encrypted partition.)
This is pure hacking, I don't know why mkinitrd uses /dev/rootdev here.
**Verifying presence of aes module
Mkinitrd looks for aes.ko by scanning modules.dep. In the latest version of Fedora, FC3 with the 2.6.10-1.760_FC3 kernel, the aes module is actually aes-i586.ko, not aes.ko. Rather than modify mkinitrd to handle this difference I copied aes-i586.ko to aes.ko, in the same subdirectory, and then ran depmod to register the change in the modules.dep file:
# cd /lib/modules/2.6.10-1.760_FC3/kernel/arch/i386/crypto
# cp aes-i586.ko aes.ko
# depmod -a
**Running mkinitrd
Mkinitrd can now be run, as described in your article, to produce the initrd file. I will use initrd.gz as the file name in the rest of this desciption, although it can be named anything (initrd-.img is commonly used).
**Copy files to USB Flash key
I copied /boot/vmlinuz-2.6.10-1.760_FC3 (shortening the name to vmlinuz for convenience) and the new initrd file, initrd.gz, to the root of the USB Flash disk. Alternativley you can have mkinitrd write the new initrd.gz file directlly to the USB Flash disk, as done in the artilcle.
**Booting with syslinux
Rebooting the PC with the USB Flash key inserted displays some information and presents the syslinux prompt: boot: Enter the name of your kernel file and the keyword "initrd=" followed by the name of your initrd file:
boot: vmlinuz initrd=initrd.gz
Alternatively, the required boot directions can be put in the syslinux.cfg file and referenced with a label at the prompt.
How about encrypting just a file?
I only need to encrypt a few files, how can I do that?
Plan Text?
While I found the article interesting and informative, I did have one issue with this configuration: the key is kept in plan text on the USB device. Wouldn’t it be better to create a program that could reliable create a 256bit key from an 8 to16 byte pass phrase? In this way, even if someone borrowed your USB device they still wouldn’t be able to access the machine without the pass phrase.
I missed the article on encrypting the home directory, but from the references made to it in this article I think it suffers from the same issue. It doesn’t really protect against physical attack as the password is in plan text on an unencrypted partition on the same machine. As an attacker all I would have to do is plug your hard drive into my machine, mount the root directory, get the key, then mount the encrypted drive. If I was willing to steal your computer to get to your data, then this presents no barrier. On the other hand, if they key is generated via an md5 (or some other) hash, then I’m still stuck trying to brute force it.
I’ve often thought of modifying the kernel code for ext3 so that unless my kernel was used to access the partition, it would be so many meaningless bits.
- John T. Williams
Re: Plain Text
I do assume that the USB drive is protected and not used for any other purpose than to unlock the root filesystem. You have to get a foothold as far as trust goes and if you read the article closely, I have choosen to trust the USB drive and the laptop's firmware.
The threats you introduce are addressed in the attack tree I present at the end of the article (steal computer and USB flash drive with key). My counter to this attack is to treat the disk as a key and protect it from theft.
Using a passphrase in addition to the physical USB key as you recommend would add an additional layer of protection. One could certainly do this if they determined that the threat warrants it.
Also, the encrypted home directory article does not instruct one to store password in plain text on an unencrypted partition. Pam_mount can read an encrypted key and decrypt it using one's system authentication token. This is the technique I recommended and it relies on a strong system authentication token.
Should have been Plain Text;
Should have been Plain Text; damn dyslexia!
is it possible to encrypt wit
is it possible to encrypt with 1344 bit triple blowfish?