Security

Tin Hat: secured by running from RAM

Security measures generally fall into one of two categories. Either they are reactive like anti-virus software and respond to intrusions as they arise, or they are architectural like file permissions, and built to prevent intrusions in the first place. Tin Hat Linux, a project undertaken by D'Youville College in Buffalo, New York, falls firmly into the architectural category. By running a security-hardened operating system entirely in RAM — preferably while using encrypted drives for storage — Tin Hat attempts to deter attackers even if they have physical access to the system. The result is a distribution that trades off a challenging install and a slow system boot in favor of high security and fast applications, a mixture of weaknesses and strengths that may put off as many users as it attracts.

Anthony G. Basile, Chair of Information Technology at D'Youville College, says, "Tin Hat was started during a modern operating system course I taught. We started looking at security issues regarding the kernel and then worked outward. Eventually we came up with the idea of building our own distro to include these ideas."

Basile explains, "This is how we picture someone using Tin Hat. They boot off the CD (or pen drive). Then use a key file from a pen drive, plus passphrase, to unencrypt their drives. They do their work and then shutdown."

Preparing to use Tin Hat

Before you use Tin Hat, ideally you should have a working familiarity with Gentoo Linux — or, more specifically, with the Hardened Gentoo project, which Tin Hat is specifically based upon. Without this background knowledge, you may find yourself scrambling to understand some aspects of Tin Hat, particularly the instructions for encrypting drives. You also need a machine with at least four gigabytes of RAM, and preferably eight, since 3GB will be taken up by the operating system.

Understand, too, that the x86 and AMD64 images on the site are not live CDs; instead they are what the project refers to as "prebuild images." That is, they are not usable versions of the distribution in themselves, but the tools that you use to create the ISO image you will boot.

This installation process is very hands-on, and has little similarity to that of any modern major distribution. For this reason, you should also read the project's thorough but slightly chatty Quick Start documentation. Much, if not all of the documentation, is available after a prebuild image loads, but you should understand what you are undertaking before you start, and possibly research any concepts with which you are unfamiliar.

In fact, you may want to print out the Quick Start, or display it on another computer to assist you while you work, particularly if you are not at least vaguely familiar with basic administrative commands like ifconfig or common configuration files like xorg.conf. Some familiarity with filesystem encryption won't hurt, either.

Building and installing an image

The purpose of the prebuild CDs is to create a workable image customized for a specific machine. To use a prebuild, burn a CD from an image downloaded from the project site, then use it to start the system on which you plan to use Tin Hat. Either the CD will open a GNOME desktop or else you will have to enable video from the shell prompt, an option that seems most likely if you are using a large widescreen monitor.

Assuming you have some knowledge of GNU/Linux systems, you should have few problems building a custom image if you follow the steps in the Quick Start. The process consists of ten steps, the first five of which are basic configuration: Changing the default passwords that come with the prebuild CDs, and setting up video, networking, sound, and printing. Much of this hardware should be detected by default, but, if any is not, the Quick Start gives you detailed instructions on the steps you should take, as well as some basic suggestions for troubleshooting.

With the sixth step, the process becomes more esoteric. Since RAM is in short supply, you need to be sure that the amount of memory allotted to tmpfs, the RAM-based filesystem, still leaves you with at least a gigabyte or so to run programs. More, of course, is desirable.

In the next two steps, you have the option of installing and upgrading applications, and configuring a new kernel. These steps ensure that the image is current, but, between the two of them, can take well over an hour — likely more — to complete.

These steps are followed by the optional preparation of an encrypted filesystem on either a hard drive or a flash drive that you can use to store your personal files when using Tin Hat. As the Quick Start explains, because the entire operating system is loaded into RAM, you can encrypt an entire device, and have no need for an unencrypted /boot partition. "Encrypting the entire block device this way," the Quick Start suggests, "makes it difficult for an attacker to know whether he is looking at encrypted data or random noise" — although in practice, a competent cracker would probably assume encryption.

Tin Hat favors the use of loop-aes, but also supports the use of dm-crypt, although, presumably because of dm-crypt's emphasis on external drives, its use is not recommended for hard drives. The Quick Start, however, does suggest using dm-crypt's cryptsetup to prepare a flash drive before encrypting it. Fortunately, the detailed instructions are enough to guide even relative newcomers to cryptography through the necessary steps.

The final step is to build the ISO. In this step, you use shell scripts stored in /home/thuser/SAVE to remove entries from system logs, and build the image so that you can either burn it or install it on a flash drive.

Booting into Tin Hat

Because Tin Hat does not run from a hard drive, its boot time is about twice that of most distributions if you are booting from a flash drive. If you are booting from CD, the time can be up to four times slower than a distribution on a hard drive, depending on the speed of your CD drive. Most of this boot time is required to uncompress the squashfs filesystem of the image and copy it into RAM memory.

However, when Tin Hat finally loads, you are compensated for the slow boot time. True, Tin Hat's lightly branded GNOME desktop is unremarkable, and there is little to say about the software except that the selection and the currency is what you chose to make it when you created the image you are using. But, because applications run from RAM rather than the hard drive, they open and close at fractions of the usual speeds. For some, this speed may be almost as important a reason for running Tin Hat as security.

Running in RAM also has the advantage of reducing the inconvenience of at least one security feature. Although Tin Hat includes almost twenty services, only a third are started at boot time, in keeping with the basic security premise of minimizing them. On a system running from a hard drive, starting each additional service would generally involve a small but noticeable delay. However, because Tin Hat runs from RAM, the delay is no longer noticeable — even though you do still have to manually start most services.

But running in RAM also creates other problems. If you find that you neglected to include essential software in the image, you must either create and burn another image or install the extra software each time you boot into Tin Hat. You must remember, too, to save your work to a hard drive or removable device, or else you lose it. For full security, you should save to an encrypted filesystem, although the choice is yours

Even more significantly, if you are running the minimum 4 gigabytes, you are more or less confined to basic productivity and Internet use; Tin Hat itself uses three of those gigabytes, and does not use a swap file, simply killing programs when it runs out of memory. While for many people, this functionality is probably enough, some might find these limitations too high a price to pay for a system that disappears when you turn it off. But, if the system gets infected, you can do a completely clean reboot.

The limits of Tin Hat

Tin Hat is unquestionably more secure than the average distribution, although its installation is rough and ready by modern standards. However, as the project itself admits, Tin Hat is only a "baby step" towards a completely secure system. In fact, the project site suggests that a completely secure system is likely impossible.

For one thing, some compromises in security are necessary just to allow the X Windows System and GNOME to run. More importantly, Tin Hat has yet to provide protection against cold boot attacks, in which data in RAM is recovered even after rebooting, or msramdmp, an application that can recover the tmpfs root file system. Nor can any security measures, no matter how ingenious, protect against social engineering attacks or simple human carelessness, such as leaving a system unattended.

Still, within these limitations, Tin Hat remains an intriguing possibility for the security-conscious. For others, the usefulness of Tin Hat depends on whether they are willing to endure the assorted inconveniences in return for greater peace of mind. Many, I suspect, are not.

Comments (1 posted)

New vulnerabilities

avahi: denial of service

Comments (none posted)

evolution-data-server: multiple vulnerabilities

Comments (none posted)

ffmpeg: several vulnerabilities

Comments (none posted)

glib: attacker-supplied code execution

Comments (none posted)

gst-plugins-base: arbitrary code execution

Comments (none posted)

icu: content protection mechanism bypass

Comments (none posted)

libpng: memory leak

Comments (none posted)

libsoup: arbitrary code execution

Comments (none posted)

mldonkey: path traversal

Comments (none posted)

mod_security: denial of service

Comments (none posted)

Opera: multiple vulnerabilities

Comments (none posted)

perl-MDK-Common: privilege escalation

Comments (none posted)

TMSNC: arbitrary code execution

Comments (none posted)

weechat: denial of service

Comments (none posted)

wesnoth: multiple vulnerabilities

Comments (none posted)

yaws: denial of service

Comments (none posted)

Page editor: Jake Edge
Next page: Kernel development>>