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 email@example.com.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
- Parsing an RSS News Feed with a Bash Script
- Tech Tip: Really Simple HTTP Server with Python
- Rogue Wave Software's Zend Server