Editor's Note: The following is an excerpt from Chapter 13, "Kernel Enhancements", of Linux Firewalls, 3rd Edition, written by Steve Suehring and Robert Ziegler and published by Novell Press. ISBN: 0-672-32771-6.

GrSecurity, formally known as Greater Security, is a kernel patch and userspace program for enhancing the security of a Linux system. GrSecurity, also referred to as Grsec, closes some avenues for attack and makes others much more difficult. Grsec implements a sophisticated Access Control List (ACL) for objects in Linux. The ACL can be used to provide much more granular control over files and other resources. For example, using a Grsec ACL, you can control what files will be shown as the result of a find command or which processes are included in process accounting logs.

Grsec also enables a system called PaX to restrict the capability of processes to alter memory space. This aspect alone renders many types of attacks involving overflows completely ineffective. Grsec also provides other protections such as stack randomization to make attacking the computer a more difficult task.

Because you've already downloaded the patch in a previous step, now it's time to patch the kernel source. The problem is that you have an already-compiled version of the kernel in /usr/src/linux. That version has a known-good configuration file, but there are other files that will interfere with the patching process. Therefore, you'll need to clean up that area before patching the kernel with Grsec.

Usually the configuration file is copied to the /boot directory. However, at this point there's no reason to assume anything. Therefore, as a first step, copy the existing kernel configuration file to another location so as to preserve its contents:

cp /usr/src/linux/.config /root/.config-kernel-<NNNN>

Replace <NNNN> with the kernel version.

Now change directory into /usr/src/linux and clean up the source tree:

cd /usr/src/linux
make mrproper

Copy the configuration file back into the kernel source tree:

cp /root/.config-kernel-<NNNN> /usr/src/linux/.config

Now it's (finally) time to apply the Grsec patch. Change directory into /usr/src; if the Grsec patch isn't there already, copy it there from the location you saved it to when you downloaded the patch earlier in the chapter.

cd /usr/src

Optionally, if the patch isn't already there, use this:

cp <download-location>/grsec-<NNNN>.patch /usr/src

Apply the patch, replacing <NNNN> with the Grsec version corresponding to your kernel:

patch -p0 < grsec-<NNNN>.patch

You'll now see output similar to the following, which was generated from a patch application on version 2.4.25 of the kernel:

patching file linux-2.4.25/Documentation/Configure.help
patching file linux-2.4.25/Makefile
... (continued)
patching file linux-2.4.25/net/socket.c
patching file linux-2.4.25/net/sunrpc/xprt.c
patching file linux-2.4.25/net/unix/af_unix.c

Grsec includes more than a few features, not all of which are relevant to every situation. Some of the features available with Grsec are specialized to certain situations, and some are very advanced, requiring extensive additional configuration to work properly. Enabling some of the Grsec options is simply a matter of turning them on within the kernel configuration. This section examines the Grsec options.

Security Level

Grsec enables you to select one of four security levels, three of which are predefined. The predefined security levels include Low, Medium, and High, with the fourth level called Customized. One method for evaluating Grsec and its features is to apply the Low Security Level, compile, and run with the kernel as such. If you notice no ill effects of running with the Grsec-Enhanced Low Security Level, apply the Medium Security Level, compile, and run with that. Increase the security level to the highest level possible.

Recommendation: Choose one of the default provided security levels and increase as much as possible, or choose a customized level and work through the other options contained in this section.

PaX Control

PaX Control provides a means to defend against certain types of exploits that attack a program's address space. For instance, PaX Control can give protection against both stack and heap-based buffer overflows, among other things. Also included is integration between PaX and Mandatory Access Control (MAC) functions.

Recommendation: Use your discretion. Some of the PaX options can be more involved to configure properly.

Address Space Protection

Address Space Protection provides many useful options that can enhance security, including prevention of methods to inject code into a running monolithic kernel. Some of the options included within Address Space Protection can break applications, most notably X Windows. Therefore, if you use X Windows, extra caution should be taken when choosing Address Space Protection options.

Recommendation: Enable these options unless you're running X Windows. If you're running X Windows, be wary of these options. These protections are great enough that it is worth a potential recompile in case one of the options breaks an application.

ACL Options

ACL Options provide some additional features that can be used when the Access Control List system is enabled through Grsec. Some options are set based on your policy, such as password lockout for the ACL system.

Recommendation: If you're going to be using the Grsec ACL system, set these options as appropriate for your environment.

Filesystem Protections

The Filesystem Protections provided by Grsec enable the additional chroot restrictions that should be used if you're running applications in a chroot. Other protections are also provided within this option area, including restrictions on symlinks, the proc filesystem, and FIFO restrictions.

Recommendation: You can greatly enhance security by enabling these options, especially including the chroot options if you're using chrooted applications.

Kernel Auditing

A group of options that provides useful logging and tracking options can be found within the Kernel Auditing area. Included within this area are such things as logging for time changes, filesystem mounting and unmounting, and even logging every call to the execve() system. Some of these options can create huge log files but are invaluable when performing forensics on a successful attack.

Recommendation: Enable as many of these options as possible. However, be careful not to fill up your log directory filesystems because of the number of entries created with things like Exec logging.

Executable Protections

Four important options appear within Executable Protections. These include options to prevent local users from possibly gaining extra privileges or gathering information about the system. Even if you aren't intending to allow "shell" (think: command-line) access to users on the system, an attacker's goal in life is to gain that shell access. These options can help prevent the attacker from gaining additional privileges if the attacker happens to gain shell access.

Recommendation: Enable these options if possible in your environment.

Network Protections

Providing a broad range of helpful additional security are the Network Protections within Grsec. Randomization is a key component of these protections and can make it more difficult for an automated scan or probe to identify your operating system.

Recommendation: Enable as many of these options as possible in your environment.

Sysctl Support

Using Sysctl, you can enable many of the features of Grsec individually to help in troubleshooting. This is particularly helpful when you're first using Grsec in case an application won't start and you believe it to be because of a Grsec option. Using Sysctl, you issue an echo command to enable some of the various features that were compiled into the Grsec kernel. When you have a stable system, you then issue another echo command to effectively "lock" the environment, preventing the Grsec features from being disabled without a reboot. If you fail to lock the environment and you don't recompile to disable Sysctl support, an attacker can remove the Grsec protections, thus making them useless!

Recommendation: Enable Sysctl support when first getting acquainted with Grsec. When you have a system that is stable with the various Grsec options that you've chosen, recompile the kernel to remove Sysctl support. Failure to do so can completely negate any Grsec enhancements.

Logging Options

The Logging Options area controls the performance of Grsec logging. Within this area you'll find options to configure the number of messages that can be sent within a certain (configurable) time period. This can help prevent possible denial-of-service attacks resulting from an attacker causing log file filesystems to fill up or creating noisy logs.

Recommendation: Set these options as appropriate for your environment.

Building the kernel with Grsec is, in effect, no different from building another kernel. You've already applied the patch and, hopefully, chosen the options you would like to try. From here, back up to earlier in the chapter and follow the instructions for compiling the kernel from source.

After you've compiled the kernel and restarted, you can begin testing the new environment. The first thing to do is to make sure that the Grsec kernel is actually running. This task is accomplished by typing this:

uname -a

You should see output containing a portion similar to the following:

2.4.25-grsec

Obviously, the kernel revision number will probably be different, but the key is to ensure that grsec appears in that name. If it does, you're running with a Grsec kernel. If it doesn't, you should examine why the kernel booted to a different version other than the one you compiled. This could be because you forgot to run Lilo or forgot to install the kernel as the final step of the compile. Refer to the section "Compiling Your First Kernel" for possible causes.

If you've chosen to enable Sysctl support so that you can enable and disable certain Grsec features on the fly, you'll find a number of files located in the /proc/sys/kernel/grsecurity directory. You can enable these options within Grsec by typing this:

echo "1" >/proc/sys/kernel/grsecurity/<filename>

Here, <filename> is the name of the option as found by doing an ls within /proc/sys/kernel/grsecurity. For example, if you want to enable the randomized process IDs (PIDs), the file is called rand_pids. You'd enable it with this line:

echo "1" >/proc/sys/kernel/grsecurity/rand_pids

After this particular option is enabled, you can run the ps command and watch new processes as they are created. They will have pseudo-random ID numbers rather than the traditional incrementing PIDs. I'd probably use the command ps auwx as root to see all the processes.

To disable a Grsec feature, simply echo a 0 to the file. For example, to disable the PID randomization that you just enabled, run the following command:

echo "0" >/proc/sys/kernel/grsecurity/rand_pids

It's important to remember that until you "lock" the Grsec features, an attacker can undo those features. The drawback is that after you lock the features, you can't undo them yourself without rebooting the computer. By locking, you prevent other features from being enabled or disabled until the server is rebooted, and this applies only if you're using the Sysctl option within Grsec. Lock the features with this command:

echo "1" >/proc/sys/kernel/grsecurity/grsec_lock

I've only scratched the surface of the benefits of GrSecurity. One of the greatest benefits of Grsec is its capability to enhance the available permissions on a file, known as Role Based Access Control (RBAC). Windows administrators who are familiar with and use the Advanced permissions that can be given to a file in Windows will want to explore these features in Grsec as well. This chapter has examined only the kernel patch portion of Grsec. There is also administration software for RBAC called gradm that enables a large set of specialized file and object permissions.