Share your story
The central voice for Linux and Open Source security news
Home News Topics Advisories HOWTOs Features Newsletters About Register

Sign up!
EnGarde Community
What is the most important Linux security technology?
Linux Events
Linux User Groups
Link to Us
Security Center
Book Reviews
Security Dictionary
Security Tips
White Papers
Featured Blogs
All About Linux
DanWalsh LiveJournal
Latest Newsletters
Linux Advisory Watch: December 12th, 2014
Linux Security Week: December 9th, 2014
LinuxSecurity Newsletters
Choose Lists:
About our Newsletters
RSS Feeds
Get the LinuxSecurity news you want faster with RSS
Powered By

Linux 2.4: Next Generation Kernel Security Print E-mail
User Rating:      How can I rate this item?
Features 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.

Capabilities: Removing Dependance on "root"

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.

Open Source Cryptography:

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 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.

"Lots of ciphers are supported -- the ones most currently used such as Blowfish, IDEA, Serpent, AES, 3DES, DES and others. Some digest algorithms are also supported - MD5 and SHA1. No hardware acceleration is supported yet. The API is mostly synchronous the way most crypto APIs are designed, but when we start getting hardware acceleration this might change and we might get an asynchronous interface -- developing this interface will probably be done with an eye on the IPSec needs. Only symmetric ciphers are supported -- no asymmetric stuff (RSA, etc.) is supported or planned."

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.

  • Encrypted swap based on /dev/loop will hopefully be work during 2.4. Swapping is a bit tricky since you can't allocate memory during write-out. In time, we might want to have a notion of an encrypted device that is controlled by a table of keys instead of a single key. One key would control a segment of the device and the individual keys could be exchangeable. This is especially useful for implementing encrypted swap. By having a table of keys, the swap code can "erase" a section of the swap-device as soon as this section becomes unused by changing a key in the key-table. This improves the security of encrypted swap for long-running servers.
  • Getting the patch integrated (with the kernel and distributions).
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:

  • IPSec being integrated in distributions
  • I am a big fan of type enforcement, so I really look forward to seeing something like the NSA-sponsored work getting integrated. I hope the Linux community sees the need for these kinds of security frameworks.
  • I also really like StegFS.

Kernel Devices and Configuration Options:

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.

Final Notes:

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 Thanks to Alexander Kjeldaas for his comments on the state of kernel crypto, and thoughts on the future.

About the Author:

Dave Wreski is the technical lead for, 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


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

Only registered users can write comments.
Please login or register.

Powered by AkoComment!

< Prev   Next >


Latest Features
Peter Smith Releases Linux Network Security Online
Securing a Linux Web Server
Password guessing with Medusa 2.0
Password guessing as an attack vector
Squid and Digest Authentication
Squid and Basic Authentication
Demystifying the Chinese Hacking Industry: Earning 6 Million a Night
Free Online security course (LearnSIA) - A Call for Help
What You Need to Know About Linux Rootkits
Review: A Practical Guide to Fedora and Red Hat Enterprise Linux - Fifth Edition
Yesterday's Edition
University of California, Berkeley Hacked, Data Compromised
London teen pleads guilty to Spamhaus DDoS
New England security group shares threat intelligence, strives to bolster region
Partner Sponsor

Community | HOWTOs | Blogs | Features | Book Reviews | Networking
 Security Projects |  Latest News |  Newsletters |  SELinux |  Privacy |  Home
 Hardening |   About Us |   Advertise |   Legal Notice |   RSS |   Guardian Digital
(c)Copyright 2014 Guardian Digital, Inc. All rights reserved.