Linux Security HOWTO
Prev Next

7. 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 it be very secure, and not be compromised. To prevent some of the latest networking attacks, you should try to keep your kernel version current. You can find new kernels at or from your distribution vendor.

There is also a international group providing a single unified crypto patch to the mainstream Linux kernel. This patch provides support for a number of cryptographic subsystems and things that cannot be included in the mainstream kernel due to export restrictions. For more information, visit their web page at: http://www.kerneli.org

7.1. 2.0 Kernel Compile Options

For 2.0.x kernels, the following options apply. You should see these options during the kernel configuration process. Many of the comments here are from ./linux/Documentation/Configure.help , which is the same document that is referenced while using the Help facility during the make config stage of compiling the kernel.

7.2. 2.2 Kernel Compile Options

For 2.2.x kernels, many of the options are the same, but a few new ones have been developed. Many of the comments here are from ./linux/Documentation/Configure.help , which is the same document that is referenced while using the Help facility during the make config stage of compiling the kernel. Only the newly- added options are listed below. Consult the 2.0 description for a list of other necessary options. The most significant change in the 2.2 kernel series is the IP firewalling code. The ipchains program is now used to install IP firewalling, instead of the ipfwadm program used in the 2.0 kernel.

  • Socket Filtering (CONFIG_FILTER)

    For most people, it's safe to say no to this option. This option allows you to connect a user-space filter to any socket and determine if packets should be allowed or denied. Unless you have a very specific need and are capable of programming such a filter, you should say no. Also note that as of this writing, all protocols were supported except TCP.

  • Port Forwarding

    Port Forwarding is an addition to IP Masquerading which allows some forwarding of packets from outside to inside a firewall on given ports. This could be useful if, for example, you want to run a web server behind the firewall or masquerading host and that web server should be accessible from the outside world. An external client sends a request to port 80 of the firewall, the firewall forwards this request to the web server, the web server handles the request and the results are sent through the firewall to the original client. The client thinks that the firewall machine itself is running the web server. This can also be used for load balancing if you have a farm of identical web servers behind the firewall.

    Information about this feature is available from http://www.monmouth.demon.co.uk/ipsubs/portforwarding.html (to browse the WWW, you need to have access to a machine on the Internet that has a program like lynx or Netscape). For general info, please see ftp://ftp.compsoc.net/users/steve/ipportfw/P>

  • Socket Filtering (CONFIG_FILTER)

    Using this option, user-space programs can attach a filter to any socket and thereby tell the kernel that it should allow or disallow certain types of data to get through the socket. Linux socket filtering works on all socket types except TCP for now. See the text file ./linux/Documentation/networking/filter.txt for more information.

  • IP: Masquerading

    The 2.2 kernel masquerading has been improved. It provides additional support for masquerading special protocols, etc. Be sure to read the IP Chains HOWTO for more information.

7.3. 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 provide 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 required. 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.

The only difference between the two devices, 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 entropy 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:


	root#  head -c 6 /dev/urandom | mimencode
This will print six random characters on the console, suitable for password generation. You can find mimencode in the metamail 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.


Prev Home Next
Password Security and Encryption   Network Security