I recently upgrade my old RedHat 9 server to Fedora Core 5 and unexpectedly had to explore some of the intricacies of Security Enhanced Linux. The need to upgrade my home server came after I wanted to expose some public services, like a web server, to remote users. I was leery of opening ports on a server I hadn’t upgraded for more than two years. Upgrades to RedHat 9 were easy when I first installed it. The O/S came with the RedHat Network, a service that allowed me to upgrade packages with the click of a button. But then RedHat dropped the free RHN service, and I left my packages to languish in old, and probably insecure, states.

When I wanted to add a public web server to the box, I first considered trying to figure out how to upgrade its RH9 packages. I found that during my period of upgrade negligence, kind folks have replaced the RedHat Network by offering “legacy” upgrades to all sorts of packages, built for RedHat 9. I could even install the Yum package-management utility to make upgrading easier.

Rather than go the easy route, and since I wanted to upgrade my 2.2 kernel anyway, I bit the bullet and downloaded the FC5 ISOs. From what I read about upgrading versus a fresh install, I went with a full install. Developers who went the upgrade route from RH9 reported big problems. I began by backing up important data onto a second hard drive (formatted as ext3) installed in the box — which was the start of my upgrade problems, since the second hard drive is 80 GB and the computer’s BIOS doesn’t recognize anything larger than 32 GB. But I optimistically believed if RedHat 9 could work with this drive, certainly Fedora Core 5 could.

The install went relatively well on my old Micron Pentium III, maxed out at 384MB of RAM (did I mention it was old?). I tried the graphic installation, but that failed and completely locked the computer, requiring a hard reset. The Fedora Core 5 installer couldn’t handle the video built into the motherboard. It didn’t fail right away, of course. It first walked me through several steps before locking the computer. Once I went to the text-only install (which was more familiar to me after years of installing versions of RedHat Linux since its 4.x days), the install proceeded mostly uneventfully.

With FC5 installed, I tried to mount the second hard drive so I could restore my precious data. I used the *exact* same fstab entry I had used under RedHat 9 — which should work, right? Nope. I got an error messages about the drive not being formatted. I will mention that I was ultra-cautious during the install not to format this second device, hdb. I spent lots of time with online manuals, including the Large Disk HOWTO and the man pages for parted, fstab and mount.

After trying many different ways to mount the drive, a Maxtor 4K080H4, and using the parted command to examine the partition table, the mount command seemed to get confused by a tiny DOS partition on the disk. The DOS partition holds the bootable MaxBlast utility I had used on an older Linux box. The computer would boot to MaxBlast, which would perform some code to fool the BIOS into recognizing the 80 GB hard drive, then it would boot Linux.

The magic solution came with adding a boot parameter, hdb=remap. From what I’ve read online, it appears the newer Linux kernels don’t automatically skip over the MaxBlast hard drive utility. The Large-Disk-HOWTO manual even mentions using “hda=remap” as a way to solve some problems, but on my initial readings, I didn’t realize those problems were my problem because I wasn’t booting off of this second drive, just trying to mount it.

On to the SELinux issues.

FC5 comes with SELinux (Security Enhanced) built into the kernel. I had heard of SELinux, but I always had thought of it as its own distribution and not something other distros were using. The security enhancements are defined as policies, which tell the kernel what an application is allowed to do, what types of files it can access, where an application should be run from, and probably many more settings. Looking back at all the SELinux problems I have had, I conclude that every one of my SELinux problems stem from not understanding its complexities. This seems to be the case for most SELinux users out there. In trying to solve my issues, I have read several mailing lists and blogs where users or vendors conclude that the way to solve SELinux problems was to disable it.

My first SELinux problem came with configuring Apache httpd. I configured httpd’s DocumentRoot in httpd.conf to a directory in my second hard drive, the very one I had problems mounting initially. I’d start httpd and it would tell me it couldn’t access the document root directory. All permissions (that I knew of) were set correctly. There was no reason at all httpd shouldn’t be able to read its document root directory. No reason — except for SELinux.

When SELinux on FC5 sees and stops a security violation, it writes an entry into /var/log/messages, but otherwise gives no other indication that it intervened and silently halted some activity. Fedora Core 6 is supposed to improve on this silent failure mode by introducing setroubleshoot. After I learned to check the system log for SELinux-related failures, here’s what I found:

kernel: audit(1154839467.971:11): avc:  denied  { search } for  pid=29238 comm="httpd" name="/"
dev=hdb5 ino=2 scontext=user_u:system_r:httpd_t:s0 tcontext=system_u:object_r:file_t:s0 tclass=dir

It took me a while to learn to read these entries. It means the “httpd” application was denied permission to search (the “x” in the usual directory mode permission) the top-level directory on the hdb5 mounted file system. The name="/" threw me off at first because “/” is mounted on a completely separate hard drive. Apparently, SELinux knows only that the directory in question was the top level on the device it was trying to search, and doesn’t bother to let you know the actual mount path to it.

The scontext is the source context SELinux was expecting to find for that resource. This context is defined in an SELinux policy somewhere, which defines what “httpd” should be allowed to do. The tcontext was the target context SELinux actually found for the resource it was trying to access. In the SELinux view, every file, directory and resource on the computer has a security context. You can configure SELinux to define what should be able to access what.

My conclusion: SELinux is pretty spiffy — until you violate a security policy and can’t figure out how to solve it. SELinux on FC5 seems like a complicated burglar alarm: you don’t use it because you can’t figure out what all the buttons are for. The lack of good SELinux documentation is defeating the SELinux goal, which is to protect the system from intentional attacks and unintended goofs. I’m hoping FC6’s release, planned for next month, will make SELinux on Fedora simpler to use — and more transparent when it intervenes. A burglar alarm won’t ring when it’s shut off.