Paranoid Penguin - Customizing Linux Live CDs, Part III

Further notes on custom live CD security.

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!

______________________

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Upgrading kernel in the live-cd

kb's picture

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?

White Paper
Linux Management with Red Hat Satellite: Measuring Business Impact and ROI

Linux has become a key foundation for supporting today's rapidly growing IT environments. Linux is being used to deploy business applications and databases, trading on its reputation as a low-cost operating environment. For many IT organizations, Linux is a mainstay for deploying Web servers and has evolved from handling basic file, print, and utility workloads to running mission-critical applications and databases, physically, virtually, and in the cloud. As Linux grows in importance in terms of value to the business, managing Linux environments to high standards of service quality — availability, security, and performance — becomes an essential requirement for business success.

Learn More

Sponsored by Red Hat

White Paper
Private PaaS for the Agile Enterprise

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.

Learn More

Sponsored by ActiveState