Next Previous Contents

10. Kernel Security

This is a description of the kernel configuration options that relate to security, and an explanation of what they do, and how to use them.

As the kernel controls your computer's networking, it is important that the kernel is very secure, and the kernel itself won't be compromised. To prevent some of the latest networkworking attacks, you should try and keep your kernel version current. You can find new kernels at ftp://ftp.kernel.org

10.1 Securing Hosts with Many Users

Your terminal servers, or servers with many users, can be further protected by employing Solar Designer's <[email protected]> experimental ``Secure Linux'' kernel patches. As this is still experimental, and not a guaranteed fix, this patch is typically only advisable for hosts with many users, and not servers such as web or email servers. His work states he has done the following:

See the documentation that comes with the software for more information.

10.2 Securelevel, Capabilities and Linux-Privs

Much of the security work being done these days is to prevent someone from ``upgrading'' their normal user privileges, and becomming root. If we could remove that ability entirely, it may help to solve many of the exploits we currently see.

Andrew Morgan has written a series of kernel patches, called Linux-Privs works towards implementing POSIX.1e (formerly POSIX 6) security model under Linux. It is a scheme that more precisely defines device and application permissions. Andrew states, Typically, the user will have to authenticate himself to such an applciation before it will perform its privileged task. This new scheme for system privilege lends itself well to restricting privileged access to the system and reduces the risk of intruders or poorly written applications running amok on the system.

There is an introductory document available at http://www.kernel.org/pub/linux/libs/security/linux-privs/doc/linux-privs.html/linux-privs.html which discusses the features he has implemented, as well an outline for those which still need to be worked on. Some of the available abilities include Access Control Lists (ACL), Mandatory Access Control (MAC), and Kernel-level auditing.

To quote James T. Dennis <[email protected]> in the July 1998, issue of Linux Gazette (available at http://www.ssc.com/lg/)

One approach would be the POSIX.1e ``capabilities'' (which are more like VMS style ``privileges'' than true ``capabilities''). There is a bit of preliminary work being done on this in the 2.1.x kernels --- but nothing is likely be usable in 2.2 (so you're looking at Linux 2.4 before there is "stable" support for any of that).

Another approach is to limit the damage that ``root'' can do using something like the BSD securelevel features. Last I heard on the Linux kernel mailing list they had dropped plans to put in simple ``securelevel'' support in favor of a ``more flexible'' approach --- which would mesh better with the eventual POSIX.1e (``Orange Book'') work.

His discussion is really based on further securing the chroot() function call using ``capabilities'', but has some generally useful descriptions as well. You can find this discussion at http://www.ssc.com/lg/issue30/tag_chroot.html

Briefly, it will allow you to disable access to functions such as mknod(), chroot(), mount(), etc, and move the privileges to the executable itself, rather than simply by being the root user.

There is further information in the Linux kernel 2.1.x sources, as well as the June 25 issue of Linux Weekly News available at http://www.lwn.net/980625/

10.3 Kernel Compile Options

10.4 Kernel Devices

There are a few block and character devices available on Linux that will also help you with security.

The two devices /dev/random and /dev/urandom are provided by the kernel to retrieve random data at any time.

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. (Perhaps the best thing to do is to use it when you're generating sensitive keying information, and you tell the user to pound on the keyboard repeatedly until you print out "OK, enough".)

/dev/random is high quality entropy, generated from measuring the inter-interrupt times etc. 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:

               user@myhost# 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.

Thanks to Theodore Y. Ts'o, Jon Lewis, and others from Linux-kernel for helping me (Dave) with this.



Next Previous Contents