The past couple months, I've been showing how to create your very own customized Ubuntu live CD. In “Customizing Linux Live CDs, Part I” (LJ, May 2008), I provided a basic procedure for mounting an Ubuntu Desktop 7.10 ISO image; removing, adding and updating its software packages; and repacking it into a new ISO image.

In Part II (LJ, June 2008), I showed how to create an encrypted virtual disk volume using TrueCrypt and explained how to use it in conjunction with your customized live CD—for example, by mounting it over the live CD default user's Documents folder.

This month, I wrap up the endeavor with some odds and ends, including my thoughts on network dæmons and firewall scripts, on plausible deniability scenarios and why you probably don't need to bother trying to enable user logins with your live CD.

As I was wrapping up Part II last month, I mentioned that the default account on Ubuntu live CDs, ubuntu, has no password. And, I implied that next time we might talk about “fixing” that.

At least, that's what was lurking at the back of my mind when I wrote the article. Why not, I wondered, set a password for the ubuntu account on the live CD, and configure GDM to start with a logon prompt?

But, the more I think about this, the less I think it's worth the effort. Let me take a few minutes to discuss why that may be.

Security is all about risk management. What controls can be employed to reduce or eliminate the risk of some bad thing happening? Is that risk likely enough to be worth the trouble of the controls? Does the control itself add other risks?

We set up accounts with passwords in order to mitigate the risk that some unauthorized person may gain access to system resources or data. On a system that has multiple users, or that is reachable over networks (especially if it's always connected), this is a serious risk.

But on an ephemeral system, such as a live CD with no hard drive of its own, there are better ways to protect access and data. Access is controlled easily by setting up your live CD so that when booted, it doesn't run any network services to which unauthorized users can connect. You can protect your personal data by keeping all of it elsewhere—for example, on a TrueCrypt-encrypted volume on a USB drive, which I showed you how to set up last month.

The sad fact of the matter is that anybody with physical access to your live CD in any form (burned onto a CD, or stored as an ISO image) can simply recustomize it using the same procedure you used and delete the password field in your custom user account's entry in /etc/passwd. Or, more likely, the attacker can skip customizing it all together and simply mount and copy the interesting parts of your squashfs image. No boot, no login!

This is the same reason that with “normal” Linux systems (hard drive or Flash-based systems) physical access is so important. Unless you're using encrypted system volumes, anybody with physical access to your Linux computer can reboot from a live CD, mount your hard drive, and copy and alter system files at will.

So again, the best way to protect the data you use with your live CD is to store it on an encrypted volume—either one small enough to fit on your live CD image (assuming you can live with read-only access to that data), or one stored on a USB drive. And, the best way to control access to your live CD system is not to run any network services.

The good news here is that by default, on Ubuntu Desktop 7.10, there are only two network dæmons that run by default: the CUPS printing system and the Avahi dæmon, which is part of the Zeroconf system for automated file/music sharing and Voice-over-IP client discovery. And, of these two things, only Avahi is problematic, because CUPS listens only on the local loopback interface—by default, CUPS doesn't accept connections from nonlocal processes.

How “problematic” is Avahi? Actually, not necessarily very much so at all. Truth is, I'm not aware of any critical security vulnerabilities in Avahi. However, it is the only thing standing between you and a system that accepts no foreign connections! If you disable Avahi, your system will be completely unresponsive to port scans and security scans. If a house with locked doors is secure, a house with no doors at all is extremely secure.

Disabling Avahi is a very simple step to add to the process of customizing an Ubuntu live CD (see the Appendix for the commands described in Part I of this series). Once you've mounted your ISO, mounted your squashfs image, and chrooted yourself into your live CD image's root filesystem (steps 00 through 12 in the Appendix), you need to issue only one command:

12.5-# update-rc.d -f avahi-daemon remove

You could, of course, also run a personal firewall script to be extra safe. But in this context (bootable-CD-based desktop), I'm not convinced it's worth the trouble, if it's possible to run without network dæmons in the first place. First, you can't necessarily be sure what your local IP address and Ethernet interface names will be, if you're going to run your live CD from random hardware, such as coffee-shop workstations. This makes it difficult to write things like anti-IP-spoofing rules.

Second, neither Ubuntu nor Debian (on which it's based) has a native firewall script service. If they did, you simply could add your firewall rules to an existing script somewhere in /etc, as with RHEL and SUSE. Instead, with Debian and Ubuntu, you either need to create your own startup script or install additional software like Firestarter on your live CD image, and configure that software on some other system the way you want it on the live CD, and copy the resulting configuration file(s) over to your live CD's filesystem.

Again, in this context, going network-dæmon-free is much simpler. Note, however, that this is one of very, very few situations in which I recommend against using iptables for local protection. Ordinarily, that is an important protection!

Suppose you're a human-rights activist working in a country with a paranoid, totalitarian government, and you use a live CD for sending factual reports to the press about local civil-rights abuses. Suppose further you want to prevent your live CD or the accompanying TrueCrypt volume you keep on your USB Flash drive from being used as direct or circumstantial evidence that you've been “committing treason”.

I have three easy suggestions for you. First, don't customize your live CD; instead, use a standard live CD from Ubuntu Desktop, Linux Mint or whatever your favorite distribution is. If you've got a lot of customized but mundane settings for your desktop manager, you can store them in an unencrypted loopback file image on your USB drive and manually mount it over /etc or your home directory.

In some places in this crazy world of ours, simply possessing a CD containing Tor, Privoxy and other privacy/anonymity tools is all the proof somebody needs that you're up to no good. Besides, this has the added advantage of being less work than using a customized live CD!

Second, use a TrueCrypt hidden volume. Keep only boring things in the nonhidden part of your TrueCrypt volume.

You can refer to the TrueCrypt link in the Resources section of this article for more information, but suffice it to say that this feature takes advantage of the fact that once you create a TrueCrypt volume, its size remains constant. Empty space is filled with random data. Or, as the case may be, with random data plus a hidden volume that is impossible to distinguish from the random data, except by someone who knows both that the TrueCrypt volume contains a hidden volume and the hidden volume's passphrase.

My third suggestion is to rename the TrueCrypt binary you'll need to keep on your USB drive (because you're using a stock Linux live CD), and while you're at it, make sure your TrueCrypt volume (or volumes) isn't named conspicuously. Both the TrueCrypt binary itself (which, by default, is named truecrypt) and TrueCrypt volumes can be called whatever you like.

So, there's nothing to stop you from renaming truecrypt to something inconspicuous like cooking-schools.dat, and your TrueCrypt volume file to checkered-pants-sources.dat. Anybody who executes cooking-schools.dat will, of course, immediately see the TrueCrypt GUI, but why would someone try to execute what appears to be a data file? Note that the only feasible way to identify a TrueCrypt volume as such is to try to mount it with TrueCrypt.

By telling you these three things, naturally I trust you'll use this knowledge for good, and not for evil—for example, by committing real kinds of treason that don't involve simply speaking the truth.

In this series of columns, I've really only gotten you started down the custom live CD path, but hopefully well enough for you to figure out more ways to use and customize Ubuntu live CDs on your own. Here are a few things you might have fun figuring out:

Whether you're an intrepid human-rights activist or simply someone with a need for a maximally portable Linux system, live CDs are a handy, simple and potentially safe way to run Linux without changing or leaving any trace of itself on the hardware on which it's run.

By the way, I'm taking next month off from the Paranoid Penguin (though not from being paranoid, of course), but I'll be back in two months. Until then, be safe!