Linux 2.4: Next Generation Kernel Security

This document outlines the kernel security improvements that have been made in the 2.4 kernel. A number of significant improvements including cryptography and access control make 2.4 a serious contender for secure corporate environments as well as private virtual networking.

One of the most obvious and significant improvements in the 2.4 kernel is the packet filtering capabilities. However, there are a number of other improvements that make Linux one of the most secure operating systems available.

---------------------------------------------

As you know, the "root" user normally has complete control over all functions of a Linux box. Binding to a privileged port, loading kernel modules, and managing filesystems are examples of things that typically can only be done by root. If a regular user needed to run the "ping" command, for example, it was necessary to make it run with the privileges of the root user. The ping binary needs root privileges in order to open a raw socket (an operation managed by the kernel) to create the necessary ICMP packet for the echo request.

Another classic example is the time server, xntpd. In order to bind to the privileged ntp port, the daemon requires root privileges. If we could somehow simply supply the ntp daemon with root privileges for the time it takes to manipulate the system clock as the daemon starts, then lower its privileges to that of a normal user before processing actually starts, we can significantly reduce the potential for a programming error from compromising the whole system.

Once these privileges are relinquished, it's effectively gone until the next reboot. Even another root process cannot regain those privileges.

This is where capabilities become a critical next step in the evolution of system and kernel security. Capabilities support extends the UNIX security model and allows Linux to provide more fine-grained access to privileged system commands. It is a set of "rules" that can be assigned to processes, users, and files that even the root user must follow.

Linux 2.2 introduced basic support, but a modification by Chris Evans to the 2.4 kernel turned capabilities into a system that is largely useable and can be programmed into many of the common services, such as the ntp daemon. Chris' change involved a modification to the prctl() system call that permits a program implementing capabilities to retain its existing level of capabilities while switching from running as root to a non-root user.

Originally a POSIX.1e specification, now withdrawn but still a useful guide, Linux 2.4 implements nine of the capabilities from the original draft, and an additional twenty-one that are specific to Linux.

Some of these capabilities include the ability to change file ownership, kill processes, control kernel module management, reboot or shutdown the machine, manipulate the system clock, and more. One can immediately see how powerful this is -- processes that are normally set-user-id root such as /bin/ping or simply must be run as root can now run with just the privileges they need and no more, diminishing the likelihood of a security problem resulting in a system compromise.

Capabilities can also be controlled on a system-wide level using a "bounding set." The ability to load or unload modules might be one such capability. The CAP_SYS_MODULE might be disabled once the system has booted and entered the normal multi-user level to prohibit the loading or unloading of kernel modules essentially until the next reboot. Using the lcap command, one might disable the ability to load kernel modules using the following:

  [root@magneto /root]# lcap CAP_SYS_MODULE

This would typically be done at the first point at which all the necessary modules have been loaded. This is an effective countermeasure against a malicious intruder attempting to install a backdoor kernel module. The CAP_SYS_RAW_IO capability would also disabled to prevent hacking kernel memory directly using /dev/kmem.

A program such as xntpd might go through the following process to relinquish the rights that are not necessary for normal operation:

• Start with full root privileges as it normally does
• Bind to the privileged ntp port
• Drop all capabilities other than CAP_SYS_TIME
• Drop root privileges (preventing it from even writing to root-owned files)
• Continue normal operation as a regular administrative account

Future changes yet to be completely implemented include the modification to commands similar to chattr(1) to modify and tag files that will one day totally remove the concept of a "root" user. The goal is to provide the ability for a command-line tool to add or remove privileges in much the same way we current add or remove permissions using chmod(1).

Currently, programs need to be modified to take advantage of capabilities. With filesystem capabilities, this sometimes won't be necessary. It might go something like this:

  [root@magneto /root]# chattr +CAP_BIND xntpd

This would enable the xntpd process to bind to a socket without requiring root privileges prior to being run. Quite powerful. At the same time, it's also contains a certain potential danger due to making an unprivileged binary slightly privileged.

---------------------------------------------

Encryption is the key to the next generation of Internet communications. No longer is it possible to use the protocols that were commonplace in times before electronic commerce, companies relying on their Internet presence for interacting with customers, and even basing their corporate image on it.

Changes in the crypto export regulations in October of 2000 now make it possible to not only distribute open source cryptography from a web site freely, but also object code derived from open source software. The origin location of the source code must send a message to the Bureau of Export Administration indicating their intent.

The kernel.org web site now has a cryptography repository, and contains crypto extensions to the new 2.4 kernel that provide the ability to encrypt filesystems, create virtual private networks, and more.

I had an opportunity to speak with Alexander Kjeldaas, the lead developer for the kernel crypto work, and asked him about the state of support of crypto in the 2.4 kernel.

Quite a number of improvements have been made since the crypto that was developed for the 2.2 kernel. Alexander writes, "Previously cipher modules could be looked up by number or by name. This was to be compatible with the old /dev/loop interface that requested "transforms" by number. In 2.4, the numbering scheme is removed which means that users no longer have to include a lot of entries into /etc/modules.conf to use encrypted block devices. It also means that other developers that wants to create their own module for various projects don't have to allocate global "IDs" for their modules." Alexander continues by stating that he is confident that crypto will be integrated into the kernel, but feels there are some further code changes that need to be made before this can be done. Once these final code changes are complete, the group will push further for inclusion in the mainline kernel tree.

He also gave me some insight into what changes we can look forward to with regard to security and Linux in the future.

Update: Ask for, and you shall receive. Jens Axboe, author of the crypto loop code, dropped me a note after this article was published stating, "crypto swap should work with the loop I rewrote and is in the 2.4.2-ac series. It will be in the stock kernel soonish."

Other crypto-related stuff to look forward to:

---------------------------------------------

The 2.4 kernel includes a few block and character devices available on Linux that will also help you with security. Although not necessarily new in the new 2.4 kernel, they are relatively unknown but extremely powerful.

These devices, /dev/random and /dev/urandom, are managed by the kernel and provide random data at any time for any number of applications. This might include generating random passwords, seeding TCP sequence numbers, and even cryptographic functions.

Both /dev/random and /dev/urandom should be secure enough to use in generating PGP keys, SSH challenges, and other applications where secure random numbers are requisite. Attackers should be unable to predict the next number given any initial sequence of numbers from these sources. There has been a lot of effort put in to ensuring that the numbers you get from these sources are random in every sense of the word random.

The only difference is that /dev/random runs out of random bytes and it makes you wait for more to be accumulated. Note that on some systems, it can block for a long time waiting for new user-generated entry to be entered into the system. So you have to use care before using /dev/random.

/dev/random is high quality entropy, generated from measuring the system interrupt times and other events which are non-deterministic. It blocks until enough bits of random data are available.

/dev/urandom is similar, but when the store of entropy is running low, it'll return a cryptographically strong hash of what there is. This isn't as secure, but it's enough for most applications.

You might read from the devices using something like:

  [dave@magneto /home/dave]# head -c 6 /dev/urandom | mmencode

This will print (approximately) six random characters on the console, suitable for password generation. You can find mmencode(1) (perhaps also known as mimencode on some systems) in the metamail mail package.

See /usr/src/linux/drivers/char/random.c for a description of the algorithm.

---------------------------------------------

In this article we've covered the new features available in the 2.4 kernel. In the months to come, we expect distribution vendors to start including cryptography directly with their releases, efforts in auditing, improved access control mechanisms, and new software to be developed around these projects to increase.

Currently, there are at least three different access control projects that utilize the foundation set forth by the 2.4 kernel, many cryptography projects to provide IPSec compliance and interoperability with commercial products, and much more.

It's an exciting period in computer security.

---------------------------------------------

Special thanks to Chris Evans for his efforts, without which I couldn't have created this document. Thanks to H. Peter Anvin for his help with the crypto section and comments about kernel.org. Thanks to Alexander Kjeldaas for his comments on the state of kernel crypto, and thoughts on the future.

---------------------------------------------

Dave Wreski is the technical lead for linuxsecurity.com, co-author of the Security HOWTO and other Linux security articles and documentation. He also works with Guardian Digital, the open source security company and sponsors of linuxsecurity.com.

---------------------------------------------

You should be aware that I'm not a legal expert, and the information contained within this document (specifically with regards to the crypto section) should not be interpreted as such. While every effort has been made to provide the most accurate information available, it may be different in your particular situation, and you should be sure to contact a real legal professional before making any decision on this matter.

---------------------------------------------

The Bureau of Export Administration Website

Linux-Privs Project

Linux Capabilities FAQ 0.2

LCAP - Linux Kernel Capability Bounding Set Editor