Paranoid Penguin

This month, I conclude a three-part series on distribution-specific security features. I began with SUSE Linux 10.0, continued on to Debian GNU/Linux 3.1 and this month I discuss Red Hat Enterprise Linux (RHEL) ES 4.

Red Hat Enterprise Linux is a general-purpose Linux distribution targeted to both desktop and server markets. As the name implies, RHEL is intended to be highly robust, stable and scalable; in other words, suitable for production use across large enterprises. And, sure enough, RHEL enjoys the reputation of delivering on all counts. Like SUSE, RHEL even runs on IBM eServer z-Series mainframes.

To much greater degree than Debian, however, and to a significantly greater degree than SUSE, Red Hat adheres to a strict philosophy of less is more where bundled software packages are concerned. Whereas Debian is composed of more than 15,000 packages and SUSE of more than 4,000, RHEL ES 4 weighs in at a mere 1,730 (if you include RHES Application Server and Extras packages, which aren't part of the base OS, strictly speaking).

I don't think it's at all euphemistic to say that this is an easily defended design choice. By limiting the number of packages it officially supports, Red Hat has a much smaller attack surface (not to mention help-desk surface). Fewer packages means less complexity; less complexity means better stability and security (at least in theory).

The downside of this design philosophy is obvious. It means fewer choices in any given tool space (network servers/dæmons, encryption tools and so on), less flexibility and greater likelihood that you'll end up installing third-party packages or even compiling them yourself from source.

As I've said many times in this column, there's no harm in rolling your own, especially when that means you're compiling out (excluding) unnecessary or potentially insecure features. But, nothing beats distribution-supported binary packages when it comes to automated security updates. And, none of the major Linux distributions besides Gentoo has any automated means of applying security patches directly from source code to locally compiled software.

Furthermore, as I'm about to show, RHEL ES 4 is particularly thin in the specific realms of security-enhancing software (with the sole exception of SELinux) and security-scanning software. This doesn't mean that I think RHEL is insecure; its smaller attack surface and its excellent SELinux support are both highly significant. It does mean, however, that you've got fewer choices in how you secure your RHEL-based server or desktop system, and even fewer choices in how you use it in security applications, than is the case with other major distributions.

Red Hat Enterprise Linux ES 4 has a very easy-to-use installation GUI that, besides installing the base operating system, allows you to select additional software packages, set the root password, set up networking, enable a simple local firewall policy and enable SELinux. After the first reboot, this installer runs additional modules for setting up a Red Hat Network subscription, creating the first nonroot user account and configuring the X Window System.

Personally, I don't care for the Red Hat installer's software package selection module at all. First, it allows you to select only from a subset of the packages available on the installation medium. (That is, as far as I could tell—it could simply be that a few packages I knew were available but couldn't find, such as gnupg, were simply buried within categories in which I didn't think to look). For the packages it does display, the installer shows neither detailed descriptions nor even approximate disk space required.

In addition, its dependency-checking functionality is decidedly primitive. If the software installer can't find something it needs, it returns an error but doesn't give you any means of solving the problem (locating the missing package, deselecting or uninstalling the package with the unmet dependency and so on). Although simplicity may be a virtue, this limited functionality doesn't compare very favorably at all with Debian's aptitude package management tool or SUSE's YaST. If you want to run this installer module again after installation is complete, it's located in GNOME's Application menu under System Settings under Add/Remove Applications, though I think you might be much happier performing additional software installations using up2date or even good old RPM.

So, what security-related packages are available in RHEL ES 4? Table 1 lists most of them. In a nutshell, if you want to secure the local system, SELinux and your local firewall policy are very nearly the only tools available to you. If you want to audit and analyze the security of other systems, RHEL ES 4 has very little to offer besides Nmap.

On the face of it, this is a decent list of applications; these are all important security-enhancing tools. Notably absent, however, are:

You're perfectly free, of course, to download and compile the source code of any of these tools manually. But, you won't be able to leverage up2date's automatic update features on such packages.

So, both in terms of available security packages and the software installer itself, RHEL is a bit underwhelming. On the plus side, I do like the Red Hat Enterprise Linux installer's firewall/SELinux module (Figure 1). Both the firewall and SELinux functionality are enabled by default, and the help window on the left-hand portion of the screen explains both settings in plain language.

If you're completely new to SELinux, you can select a warn setting that causes the kernel to log events that violate the local SELinux policy without actually blocking those events. By default, however, SELinux is set to active, using a default policy that restricts the behavior of Apache (httpd), bind, NIS (ypbind), dhcpd, mysqld, ntpd, portmap, postgresql, snmpd, squid and syslogd.

Figure 1. Firewall and SELinux Configuration in RHEL ES 4

The last thing worth noting about the Red Hat Enterprise Linux ES 4 installer is that both during initial setup, when you enter the root password, and after the first reboot, when you create the first nonroot user account, the installer performs no password complexity checks of any kind (of the sort SUSE's installer performs). It doesn't even warn against choosing an overly simple password via a simple text box like Debian does.

This is unfortunate. Password guessing and brute-force attacks are still very much with us. I was pleased to see, however, that by default, the XScreenSaver utility is configured to lock X sessions by password automatically any time the screen saver kicks in. (If only those passwords that protect XScreenSaver were required to include some combination of mixed upper-/lowercase, punctuation and numerals, I'd be happier still!)

Keeping your system up to date with the latest security patches is absolutely essential on any Linux system. Red Hat was a pioneer in offering automatic updates when it introduced the combination of the up2date utility and the Red Hat Network service offering several years ago, and this system is even more mature now.

The way this works is that when you set up your Red Hat system (any current version), after the first reboot you're prompted to configure a Red Hat Network subscription. A subscription with an RHN Update entitlement is included with every Red Hat product. When prompted, you simply enter the user name and password you'd like to use (one account can be used to manage multiple systems under the same subscription), and then the subscription number printed on the Activate Your Subscription card that came with your Red Hat installation media.

The net effect of all this (no pun intended) is that you now will have an active subscription to the Red Hat Network service, with a system profile corresponding to your new Red Hat system, which in turn is associated with an RHN Update entitlement that allows your system to check for and download the latest versions of all software packages that are part of the version of RHEL you purchased.

The simplest way to check for and apply security updates is to right-click the icon for the Red Hat Network Alert Notification Tool on your GNOME desktop (it's a glowing red exclamation point if your system isn't up to date, or a blue check mark if it is), and select Check for updates, run up2date and so on, as needed.

You can set up automatic updates by logging on to the Red Hat Network Web site (www.redhat.com/en_us/USA/rhn for US users) with your RHN credentials, clicking on the Systems tab, clicking on your system's profile, clicking Properties and checking the box next to Automatic application of relevant errata (Figure 2). Obviously, you shouldn't enable this feature on high-availability or change-controlled systems, because software patches always have the potential to introduce other bugs or conflicts.

Figure 2. Configuring Auto-Updates Via the RHN Web Site

Although the up2date/RHN system is mature and feature-rich (especially for large organizations with the need and ability to pay for network management and provisioning entitlements), as a Linux desktop user, I find it more difficult to use than Debian's apt system (which is more primitive in some ways, but easier to script) or SUSE's YaST Online Update system (which is much easier to configure).

Oddly, as with many other aspects of RHEL, up2date configuration options appear to be spread across multiple GUIs, including the Red Hat Network Web site, unless of course you configure things from a shell (in which case everything you need is in /etc/sysconfig). If you administer Red Hat on servers (that may not even have the X Window System installed, which is always a good policy on hardened systems) or are otherwise command-line-centric, I'm sure up2date and other Red Hat functions are easy to learn. Ironically, I find many of RHEL's GUIs, which are, of course, supposed to simplify things, confusing. (But maybe it's just me!)

As we've seen, RHEL seems to rely very heavily on SELinux for system security. This is hardly a sloppy or mentally lazy design choice; SELinux provides a comprehensive and granular array of mandatory access controls against system users, applications, processes and files. As described in the previous section, the included targeted SELinux policy provides default controls on some of the most commonly used applications.

This default policy's behavior can be tweaked easily using the Security Level applet accessible via GNOME's Application→System Settings menu (Figure 3). The same applet can be used to configure a simple local firewall policy.

Figure 3. Security Level Configuration Applet

The implementation of SELinux in RHEL ES 4 is truly commendable for its simplicity, not to mention the very fact that it's enabled by default. That's the good news; the less-good news is that to create a custom SELinux policy, that is, one that uses tighter or looser controls than the included policy or one that addresses other applications, you're going to have to do some reading. The best place to start is the Red Hat Enterprise Linux 4 Red Hat SELinux Guide, available at www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide.

You'll also probably want to install some extra GUI tools for this purpose, too, namely the setools and setools-gui packages. These packages provide, among other things, sepcut, apol, seaudit and seuserx. For more information on what these tools do and how to use them, see the documents in /usr/share/doc/setools-1.5.1 (the directory name on your system may reflect a different version number).

I've already mentioned the Security Level applet in RHEL ES 4's GNOME desktop. Unlike with SELinux, this applet doesn't give you much more in the way of configuration options for the local firewall policy than you get at installation time. This policy allows all outbound network transactions (originating from the local system), and blocks all inbound network transactions (destined for the local system) except the services you select here. Those services are, as in the Red Hat installer, HTTP, FTP, Telnet, mail (SMTP) and SSH.

In the Security Level applet, you also can specify a list of other ports in the form [port #]:[protocol], for example 689:tcp, 53:udp, 53:tcp. If you need anything fancier than that, you have to write your own iptables statements from scratch. Happily, you can do so simply by adding or editing lines in the file /etc/sysconfig/iptables. See the iptables man page and the Red Hat Enterprise Linux 4 Security Guide for more information.

It's worth mentioning that Red Hat recently acquired Netscape Directory Server, and has updated it and rebranded it as Red Hat Directory Server. This is being positioned as a commercially supported alternative to OpenLDAP or Sun Java System Directory Server. Although not included with RHEL (it's an add-on product that costs extra), it's worth mentioning as a key component of Red Hat's security vision. RHEL does include fully supported OpenLDAP packages, however.

In the same vein, Red Hat Certificate System provides a commercially supported PKI solution. It too is an add-on product not included with RHEL. OpenSSL is included with RHEL, of course, but without any additional setup tools such as TinyCA.

I have mixed feelings about Red Hat Enterprise ES 4's security features. On the one hand, RHEL doesn't offer anywhere near as many different security-enhancing software tools as Debian GNU/Linux or SUSE Linux. Entire categories of security tools that are well represented in other major Linux distributions (integrity checkers, intrusion detection systems, virtualization environments and so on) are absent.

On the other hand, Red Hat has clearly maintained an unparalleled level of control over the size and scope of its distribution. It has made hard choices about what it will support and maintain, and what it will not, which surely reduces the attack surface of Red Hat systems. I have no doubt that Red Hat's security team has an easier time responding to vulnerabilities in RHEL's 1,730 packages than the Debian security team does with that distribution's 15,000-plus packages.

Furthermore, by not only including SELinux in RHEL 4 but enabling it by default, Red Hat has taken a very bold step. The kernel-level mandatory access controls provided by SELinux provide the potential to mitigate many of the risks one might otherwise use add-on utilities to address. Furthermore, because this sort of technology is proactive, designed to prevent bad behavior, it's inherently stronger than intrusion detection, integrity checking and other reactive technologies (though it would be better if RHEL had both proactive and reactive measures—even with SELinux, bad things can happen).

Whether you find RHEL to be lean and mean or limited and clunky will depend on your particular Linux needs. I'll allow that some of the reasons I'm not as keen on RHEL as I am on Debian and SUSE are specific to my job as a security architect and consultant. I rely on a specialized set of tools, most of which RHEL has judged to be unnecessary for its target market—presumably IT professionals in corporate settings. Still, it seems to me that if I needed to secure a corporate Web server running RHEL, with or without SELinux, I'd still want to install mod_security, Squidguard, Syslog-NG and other tools manually that RHEL presently lacks.