Encrypt Your Root Filesystem
The value /pci@f2000000/usb@1b,1/disk@1:2 comes from our earlier inspection of the Open Firmware device tree, and /pci@f2000000/usb@1b,1/disk@1 is the first disk on the USB bus on the PCI bus at f2000000. The device we are interested in is a disk, and :2 means partition 2.
4) Install the bootstrap programs and kernel to /dev/sda2:
# ybin --config /mnt/encroot/etc/yaboot.conf -v # mount /dev/sda2 /media/usbstick # cp /boot/vmlinux /media/usbstick
At this point, the crypto-aware initrd must be installed onto the Flash disk. Fedora provides a tool named mkinitrd that can create an initrd. However, at the time this article was written, mkinitrd did not know how to mount an encrypted root. The patch at https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=124789 provides this functionality. Once the patch is applied, mkinitrd reads /etc/crypttab and creates an appropriate initrd:
1. mkinitrd --authtype=paranoid -f /media/usbdisk/initrd.gz <kernel version> 2. umount /media/usbstick
The file /mnt/encroot/etc/fstab should be updated to reflect the changes made:
/dev/mapper/root / ext3 defaults 1 1
Encrypted swap or the absence of swap space entirely is a prerequisite for an encrypted filesystem. Reasons for this can be found in “Implementing Encrypted Home Directories” and in a BugTraq mailing-list thread titled “Mac OS X stores login/Keychain/FileVault passwords on disk”. When the patch at https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=127378 is applied to the initscripts package, Fedora allows users to encrypt their swap partitions using a randomly generated session key. Because swap space isn't generally required to be consistent across reboots, the session key is not saved when the system is powered down. To enable encrypted swap, complete the following steps:
1) Add the following line to /mnt/encroot/etc/fstab, replacing any previous swap record:
/dev/mapper/swap swap swap defaults 0 0
2) Add the following line to /mnt/encroot/etc/crypttab to tell the system how to perform the encryption:
swap /dev/hda3 /dev/urandom swap
At this point we should be able to reboot the system and use our encrypted filesystem. Again, we need to hold down option-command-o-f to enter the Open Firmware prompt.
As demonstrated above, the path to the Flash drive's second partition is /pci@f2000000/usb@1b,1/disk@1:2. Knowing this, we can build the path /pci@f2000000/usb@1b,1/disk@1:2,\ofboot.b. The , deliminates between the partition number and the filesystem path; \ofboot.b is the filesystem path, and \ is like UNIX's / with the filesystem root at the device's root:
> dir /pci@f2000000/usb@1b,1/disk@1:2,\
Untitled GMT File/Dir
Size/ date time TYPE Name
bytes 9/ 3/ 4 21:44:41 ???? ???? initrd.gz
2212815 8/28/ 4 12:24:21 tbxi UNIX ofboot.b
3060 9/ 3/ 4 2:21:20 ???? ???? vmlinux
141868 9/28/ 4 12:24:22 boot UNIX yaboot
914 9/28/ 4 12:24:22 conf UNIX yaboot.conf
This confirms that Open Firmware can read the files required to boot the system. Setting the value of the boot-device variable to /pci@f2000000/usb@1b,1/disk@1:2,\ofboot.b causes the system to boot from the Flash disk: setenv boot-device /pci@f2000000/usb@1b,1/disk@1:2,\ofboot.b.
Once the system successfully boots from the encrypted root, it is necessary to destroy all of the data on /dev/hda5. This can be done with the same procedure used to randomize the root filesystem's partition: dd if=/dev/urandom of=/dev/hda5. You may want to perform this overwrite several times. For one standard on sanitizing disks, see Chapter 8 of the US Department of Defense's “National Industrial Security Program Operating Manual”.
Following a safe sanitization, /dev/hda5 may be used as /home. The /home filesystem also should be encrypted. Luckily, this is a much simpler process, because the system need not boot off of /home. Creating the filesystem itself is similar to the steps taken to create the root filesystem.
1) Ensure that the aes, dm-mod and dm-crypt modules have been loaded into the kernel.
2) Unmount the partition that will host the encrypted home filesystem, /dev/hda5, from /home:
# umount /dev/hda5
3) Create a random 256-bit encryption key, and store it at /etc/home-key. One way to do this is:
# dd if=/dev/urandom of=/etc/home-key bs=1c count=32
4) Create a dm-crypt device, encrypted using the key you just generated:
# cryptsetup -d /etc/home-key create home /dev/hda5
5) Create an ext3 filesystem on /dev/mapper/home:
# mkfs.ext3 /dev/mapper/home
6) Mount the new filesystem:
# mount /dev/mapper/home /home
7) Create an entry in /etc/crypttab, so that various utilities know how the filesystem was configured:
root /dev/hda5 /etc/home-key cipher=aes
8) Finally, update /etc/fstab to contain an entry for /home:
/dev/mapper/home /home ext3 defaults 1 2
At this point, it is appropriate to begin adding nonroot local user accounts to the system. Setting up the encrypted root filesystem is now complete.
Having all of your data encrypted can be dangerous. If the encryption key is lost, your data is lost. Because of this, it is important to make backup copies of the Flash disk containing your key. It also is crucial to perform plain-text backups of the encrypted data. If you maintain a bootable rescue disk, it may make sense to rethink the system components that should be on it. A copy of your root and home filesystem keys, parted, hfsutils, the cryptography-related kernel modules and cryptsetup are excellent candidates.
How effective is this technique in protecting your data? In his book, Secrets and Lies, Bruce Schneier presents a technique that is useful in evaluating this. An attack tree can be used to model threats. Figure 4 presents the beginning of an attack tree for our encrypted filesystem. It is important to note that this attack tree is not complete and probably never will be.
By using the techniques in this article and a little creative thinking, it is possible to make the data on your hard disk more resistant to certain types of theft. It is important to keep in mind the types of attacks that circumvent these defensive techniques. Though other techniques must be used to protect against network-based and other attacks, those described here are a powerful tool toward the goal of overall system security.
Resources for this article: /article/7865.
Mike Petullo currently is working at WMS Gaming as a test engineer. He has been tinkering with Linux since 1997 and welcomes your comments at lj@flyn.org.
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
If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.
Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.
Sponsored by ActiveState
| Non-Linux FOSS: libnotify, OS X Style | Jun 18, 2013 |
| Containers—Not Virtual Machines—Are the Future Cloud | Jun 17, 2013 |
| Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer | Jun 12, 2013 |
| Weechat, Irssi's Little Brother | Jun 11, 2013 |
| One Tail Just Isn't Enough | Jun 07, 2013 |
| Introduction to MapReduce with Hadoop on Linux | Jun 05, 2013 |
- Containers—Not Virtual Machines—Are the Future Cloud
- Non-Linux FOSS: libnotify, OS X Style
- Linux Systems Administrator
- Validate an E-Mail Address with PHP, the Right Way
- Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer
- Senior Perl Developer
- Technical Support Rep
- UX Designer
- Introduction to MapReduce with Hadoop on Linux
- RSS Feeds
- Bought photoshop CS5 for developing a website :(
1 hour 48 min ago - What the author describes
3 hours 14 min ago - Reply to comment | Linux Journal
7 hours 24 min ago - Reply to comment | Linux Journal
8 hours 9 min ago - Didn't read
8 hours 20 min ago - Reply to comment | Linux Journal
8 hours 25 min ago - Poul-Henning Kamp: welcome to
10 hours 35 min ago - This has already been done
10 hours 36 min ago - Reply to comment | Linux Journal
11 hours 21 min ago - Welcome to 1998
12 hours 10 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?