Paranoid Penguin

Last month, I began a three-part series on distribution-specific security features, beginning with SUSE Linux 10.0. This month, I continue with Debian 3.1, and next month I will conclude with Red Hat Enterprise Linux.

As you may recall, unless you missed last month's column or have been enjoying yourself in memory-impairing ways since then, several things about SUSE 10.0 really struck me: its wide variety of security-enhancing software packages and security-scanning tools; its inclusion of several different virtual machine platforms; and Novell AppArmor, which adds Mandatory Access Controls (MACs) to individual applications and processes.

When I began exploring security features in Debian 3.1 (Sarge) GNU/Linux, I was therefore particularly interested to determine how does Debian 3.1 compare with SUSE 10.0 in those areas? And, what unique security features does Debian bring to the table?

Like SUSE, Debian GNU/Linux is a general-purpose Linux distribution designed to be useful in a wide variety of desktop and server roles. Also like SUSE, Debian includes a long and varied bundle of binary software packages.

Unlike SUSE, Debian is a 100% not-for-profit undertaking. There is no expensive Enterprise version of Debian 3.1 with more features than the freeware version. There's only one version of Debian GNU/Linux 3.1, and it's 100% free—;unless you purchase Debian CD-ROMs from a Debian re-packager such as LinuxCentral (see the on-line Resources), in which case you're paying primarily for the cost of CD-ROM production, not for Debian itself.

Arguably, there are security ramifications associated with any purely free software product. Business-oriented IT managers love to ask, “Who's accountable when things go wrong?” But others point to Debian's impressive record of releasing timely security patches as evidence that the Debian Security Team is at least as dependable and responsive as any equivalent commercial entity. My own opinion is that its freeness isn't a major factor one way or the other. Debian doesn't have a reputation for being any more or less secure than commercial general-purpose Linux distributions.

So, what is the Debian installation experience like, and how does it encourage good security?

Compared to other major general-purpose Linux distributions, Debian's installer is decidedly old-school. It uses a bare-bones, text-based GUI that does little more than install software packages. Although this may be off-putting to many users, especially those new to Linux, it minimizes the system resources required to install Debian and the amount of time you'll spend waiting for the installer to load itself into RAM.

Software package installation, as with any Linux distribution, is the heart of the Debian installation process, and in Debian 3.1 it's handled by aptitude. aptitude is similar to its predecessor, dselect, but with a couple of important differences. The first is that although it's text-based like dselect, aptitude sports drop-down menus you can access by pressing the F10 key. The second difference is that, for me at least, aptitude organizes packages in a much less confusing way than dselect. It's still primitive compared to the graphical package installers in SUSE, Red Hat Enterprise Linux and so on (and arguably clunkier than the text-based Slackware installer); however, aptitude is a significant improvement over dselect.

With aptitude, it's also easy to update your local package list and get the latest security patches from the Debian.org site (see Resources). In fact, anytime you install software using the Advanced Packaging Tool (apt) system (for example, when you run aptitude or apt-get), Debian automatically checks for security updates for the packages you're attempting to install.

The bad news about the Debian installer is that it doesn't seem to do very much to harden your system, even in a preliminary way. It doesn't give you an opportunity to create even a basic local firewall policy or choose a preconfigured or default policy. It doesn't even check your root and first nonprivileged-user account passwords for complexity (although it does warn you that passwords need to be complex).

Rather, it appears as though in Debian the emphasis is on providing users with as wide a variety of security-related software packages as possible, rather than actually helping users set up any of those packages. Considering that Debian consists of more than 15,000 software packages in all, you've got many choices indeed. Table 1 lists some Debian packages that directly enhance system security.

In addition to the local security-enhancing packages in Table 1, Debian includes many tools for analyzing the security of other systems and networks. Table 2 lists some notable ones.

Sifting through all these packages at installation time can be daunting. One thing that helps is aptitude's ability to search for packages by name. Another is the “Securing Debian Manual” (see Resources).

Once you've selected and installed your initial set of software packages, aptitude runs a few post-installation scripts (depending on what you installed). On my test system, I was disappointed to see very little in these scripts germane to security—these deal primarily with basic system setup, such as network settings. If you need to reconfigure these basic settings later (without editing files in /etc directly), you can re-invoke that part of the installer with the base-config command.

In summary, Debian's installation-time security features are disappointing and sparse. It may not be fair to compare the purely volunteer-driven Debian effort to a commercial product, but in my opinion, Debian sorely needs a centralized, security feature-rich installation and administration utility akin to SUSE's YaST.

Like other major Linux distributions, Debian increases in size and complexity with each new release. The paradox here is that Debian's ever-growing, almost unparalleled selection of software packages makes it more complex, even to the point of confusion—confusion causes sloppiness; sloppiness introduces avoidable security holes. A central administration utility would go a long way to reduce this confusion and enhance security for Debian neophytes and power users alike. It would go even further if it included modules for creating local firewall policies, managing virtual machines, managing SELinux or Trustees policies and so on.

All ranting aside, I like Debian, and as of this writing, I'm in the process of migrating my Web server from SUSE to Debian (though my laptop will remain a SUSE box). It's also worth mentioning that there are many unofficial Debian installers available, including other Linux distributions based on Debian and able to run Debian packages (see Resources).

So, moving on, let's talk about some particularly interesting and useful groups of security-related packages in Debian GNU/Linux 3.1.

If you want a hypervisor-based virtual machine environment, such as Xen for Debian, you need to obtain and compile source code, though that's not too huge of a barrier. Debian has no Xen packages. Debian does include, however, binary packages for two other general-purpose virtual machine environments: user-mode Linux (UML) and Bochs. (It also includes Wine, but this is more of a shim for running specific Windows applications than a virtual machine per se.)

Of Debian's two officially supported virtual machines, user-mode Linux is probably the most viable option for using virtual hosts to segregate different application environments, for example, Apache on one virtual machine and BIND9 on another. This is because of performance limitations in Bochs: Bochs emulates every single x86 CPU instruction and all PC devices. Bochs therefore would appear to be more suited to single guest-system applications, such as running Windows applications on your Linux desktop system. The Bochs Project home page (see Resources) includes official documentation and links to mailing lists, discussion boards and so forth. Debian's bochs-doc package also contains Bochs documentation.

User-mode Linux doesn't support Windows guest systems, but it is much faster than Bochs and has the added advantage of running all guest systems' kernels as nonprivileged users (that is, not as root, like the underlying “host” kernel). See Debian's user-mode-linux-doc package for more information. If you run a Debian guest on an underlying Debian host, you may need to install the user-mode-linux package (on the guest) from Debian's unstable release—the stable version is unavailable for some reason.

I must add a disclaimer at this point: I've never used UML myself, being a VMware user of long standing (see my review of VMware Desktop 5.5 on page 56). Therefore, I can't tell you firsthand how to use UML or even how well it works in Debian.

Several packages in Debian GNU/Linux 3.1 enhance local access controls. The trustees package lets you define multiple sets of permissions on a single file/directory/device object by associating a trustee object with it. For example, you can give members of the users group read-only access to the file foo.txt, and give members of the foomasters group write privileges to the same file.

A much more comprehensive set of controls is provided by SELinux, the US National Security Agency's type-enforcement and role-based access control system for the Linux kernel. SELinux makes it possible to manage users, groups and system resources with a very high level of granularity, even to the extent of making it possible to restrict root's own privileges.

The trade-off is complexity. Creating and managing SELinux policies that don't impair needed functionality can be involved. Luckily, besides its standard selinux-utils package, Debian includes checkpolicy, an SELinux policy compiler, and setools, a group of utilities for analyzing SELinux policies and managing users.

If SELinux is more than you're willing to tackle, Debian provides several other tools for delegating root's authority. sudo, of course, is the classic in this category, but there's also osh, the Operator's Shell.

Another interesting category of tools that are well represented in Debian are limited-feature Secure Shell (SSH) tools. SSH, of course, is an encrypted, strongly authenticated means of running remote shells, executing remote commands and even for tunneling other TCP-based network applications including the X Window System. But what if you want to offer users only a subset of SSH functionality—for example, encrypted file transfers, without giving them shell access?

Two Debian packages that address this problem are rssh, which allows users to use scp, rdist, rsync, cvs or sftp over SSH without actual shell access, and scponly, which allows scp without allowing remote shells.

The last category of security tools I highlight here is filesystem encryption. These are different from more general-purpose encryption tools, such as gnupg and bcrypt, which are used to encrypt individual files. Filesystem encryption tools let you encrypt entire volumes (directory structures), for example, on USB drives and other removable media.

Three Debian packages that provide filesystem encryption are cryptsetup, which manages loopback-device encryption via the Linux 2.6 kernel's dm-crypt functionality; encfs, which doesn't require use of loopback devices; and lufs-cryptofs, an encryption module for the Linux Userland Filesystem (lufs). Of the three, cryptsetup offers the best performance, because it operates at the kernel level. The user-space filesystems, encfs and lufs, work at a higher layer of abstraction than the kernel—that is, they're less efficient. They're also, however, more useful for networked filesystems.

I'd be remiss if I didn't at least briefly discuss one of my favorite characteristics of Debian, and the main reason I'm running it on my new Web server—Debian's relatively glacial release schedule. On the one hand, the delay in releasing Debian 3.1 (three years, or 21 dog/computer years after 3.0) was a bit extreme, and the Debian team has pledged a more predictable release cycle, probably one year from now on. But it's also true that stability enhances security.

Put another way, if you use Debian to run the latest desktop applications, or other things that depend on the very latest hardware drivers, you may be happier with the Debian variant Ubuntu, which has a predictable and short (six-month) release cycle. If, however, you want to build an appliance system that chugs along in a corner, requiring little ongoing maintenance other than regular security patches, Debian's longer release cycle is positively luxurious. In many situations, it's preferable to run somewhat-outdated but fully security-patched applications than it is to have to upgrade the entire operating system every six months (or sooner). I admit, however, that I am among the world's laziest system administrators!

Like UNIX itself, Debian provides the security-minded user with maximal power, flexibility and variety of tools, at the cost of complexity. Debian GNU/Linux 3.1 is probably not for you if you have an aversion to man pages or Google. But it's very flexible indeed. This article scratches only the surface of Debian's potential as a platform for secure server operations or for security scanning and auditing.

Next month, I'll conclude my “Security Features” trilogy with Red Hat Enterprise Linux. Until then, take care!

Resources for this article: /article/8885.