(LinuxWorld) -- As I wrap up my SysAdmin series on Linux security, I would like to write about something out of the ordinary; something that most people -- unless you are absolute security junkies, or Slashdot trolls -- would not know about. It's called SELinux.

SELinux, also known as Security Enhanced Linux, is a National Security Agency sponsored Linux project to develop a more secure Linux. SELinux is a set of Linux kernel patches and utilities designed around a usable but mandatory access control system.

Using SELinux will require a recompile of either a stock Linux 2.4.12 (at the time of this writing) kernel, with patches, or the downloading of the SELinux kernel distribution from the SELinux Web site (see resources below). The SELinux kernel distribution is available in several download forms. I chose the 34-megabyte package that includes Linux 2.4.12 already patched for SELinux, and the associated software utilities needed to operate SELinux. Our installation box is a stock Red Hat 6.2 machine with all relevant updates.

I am not going to go into the re-compilation of the kernel. If you are attempting to run SELinux, I'm sure that you have already recompiled your kernel ad nauseum. However, I will say that it is important to view the README files within the selinux directory that is created after unpacking the source package. Once you have read these files, recompiling the Linux kernel for the provided features is a snap.

After you have recompiled and installed the new kernel, you will need to configure your policies per the users file included in the source distribution. As I have unpacked and compiled my version of the source under /usr/src, the directory I am working in is /usr/src/selinux.

While following the instructions within the README file, I noticed a small discrepancy. In Step 5, the README instructs you to:

5) Build and install the example policy configuration:
   cd policy
   make
   su (if not already root)
   make install
   cd ..

On my system the above step failed. This was due (at least on my system) to the fact that the directory /usr/src/selinux/module/selinux_plug was not located at /usr/local/selinux. A simple ln -sf solved the problem and I was able to move on, almost. I also had to move /usr/src/selinux/module/selinux_plug/ss/checkpolicy to the /usr/src/selinux/module/selinux_plug/bin/ directory. Once these small issues had been resolved I was able to make, and install my policy.

After installing the new kernel, I rebooted and attempted to log in. My first attempt was with the root user. When I tried to log in locally as root the system would inform me of my default "role" and ask me if I would like to change it.

As part of the security architecture of SELinux, the users of the system have "roles." These roles are defined within the system policy, and do not directly relate (beyond the analogous username) to permissions on the Linux system. When set up properly (which I am still trying to do), one could assume one of many roles. You could have a user called jd who had a default role of a general user, but at login was able to select the sysadm_r role to perform functions normally reserved for the traditional root user. At this point, I am still unable to add any user to the system beyond the root user who maintains a role of sysadm_r.

One of the side effects of the SELinux security architecture is that you can not (yet) run X Window System safely. This rules out KDE and GNOME, and that will relegate SELinux to the server only.

This is not really a bad thing, as Linux has traditionally been strongest in the server market. The server is also typically where you will need the most stringent security.

I hoped that this article could be a mini-HOWTO on SELinux. Unfortunately, due to article length and the complexity of the software I won't be able to provide as much information as I would have liked.

That said, I don't want people to go away with just a brief introduction to SELinux, so I'll provide a little sysadmin tip that might save you some heartache.

As you probably know, one of the most dangerous commands that you can execute as root is rm. This is especially true if you are using the -rf flags; I have two horror stories to go with this piece of advice.

The first is when I accidentally deleted the Solaris kernel from the / partition of a SPARC machine. The machine continued to operate, but nobody could log in and an inevitable, steady, downward spiral ensued.

The second is when I deleted our entire /usr/local/pgsql/data directory accidentally. Oops. Note that the first incident was more than six years ago, and the second incident was more than three years ago. I believe I learned my lesson.

Anyway, on to the tip!

If you are running the ext2 filesystem, and most Linux systems are, you can use the chattr command on files or directories that you do not wish to be deleted. This is done with the +i flag. For example, on a Red Hat 6.2 installation the kernel is installed in the /boot directory. If you were to use chattr +i command on the /boot directory, the directory and all of its contents would be protected against accidental deletion. They would be protected even if the user that was trying to delete them was root.

There is a potential downside to the +i option, however, which is actually the same thing which makes it beneficial. It renders the directory and all of the contents underneath the directory unmodifiable. This means that you cannot add files to the directory or change the files in any way under that directory. If you need to make modifications (such as upgrading the kernel), you can turn off the feature by using the -i option with the chattr command.