Paranoid Penguin - Customizing Linux Live CDs, Part III

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.

To Log On, or Not to Log On

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.

Network Services and Ubuntu Live CDs

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!

Comment viewing options

I followed all the instruction to create a "customized live cd"
form ubuntu-8.10-desktop-i386.iso
It had 2.6.27-7 kernel. In the process, I upgraded the kernel
to 2.6.27-11, but the end CD still boots with 2.6.27-7.
What else do I need to do to be able to boot with the new
kernel?