By Kurt Seifried [email protected]
Introduction
Linux (or GNU/Linux according to Stallman if you're referring to a complete
distribution) is actually just the kernel of the operating system. The kernel is
the core of the system, it handles access to the harddrive, security mechanisms,
networking and pretty much everything. It had better be secure or you are
screwed.
In addition to this we have hardware problems like the Pentium F00F bug, and
problems inherent to the TCP-IP protocol, the Linux kernel has it's work cut out
for it. Kernel versions are labeled as X.Y.Z, Z are minor revision numbers, Y
define whether the kernel is a test (odd number) or production (even number),
and X defines the major revision (0, 1, 2 etc). I would highly recommend running
kernel 2.6.x, as of July 2005 this is 2.6.12.3. The 2.2.x series of kernel has
major improvements over the 2.0.x series. Using the 2.2.x kernels also allows
you access to newer features such as ipchains (instead of ipfwadm) and other
advanced security features. The 2.0.x series has also been officially
discontinued as of June 1999. To find out what the latest kernel(s) are simply
finger @finger.kernel.org :
[seifried@mail kernel-patches]$ finger @finger.kernel.org
The latest stable version of the Linux kernel is: 2.6.12.3
The latest prepatch for the stable Linux kernel tree is: 2.6.13-rc3
The latest snapshot for the stable Linux kernel tree is: 2.6.13-rc3-git4
The latest 2.4 version of the Linux kernel is: 2.4.31
The latest prepatch for the 2.4 Linux kernel tree is: 2.4.32-pre1
The latest 2.2 version of the Linux kernel is: 2.2.26
The latest prepatch for the 2.2 Linux kernel tree is: 2.2.27-rc2
The latest 2.0 version of the Linux kernel is: 2.0.40
The latest -ac patch to the stable Linux kernels is: 2.6.11-ac7
The latest -mm patch to the stable Linux kernels is: 2.6.13-rc3-mm1
Compiling and installing a kernel:
Upgrading the kernel consists of getting a new kernel and modules, editing
/etc/lilo.conf, rerunning LILO to write a new MBR. The kernel will typically be
placed into /boot, and the modules in /lib/modules/kernel.version.number/.
Getting a new kernel and modules can be accomplished 2 ways, by downloading
the appropriate kernel package and installing it, or by downloading the source
code from ftp://ftp.kernel.org/ (please use
a mirror site), and compiling it.
cd /usr/src
there should be a symlink called "linux" pointing to the directory containing
the current kernel, remove it if there is, if there isn't one no problem. You
might want to "mv" the linux directory to /usr/src/linux-kernel.version.number
and create a link pointing /usr/src/linux at it.
Unpack the source code using tar and gzip as appropriate so that you now have
a /usr/src/linux with about 50 megabytes of source code in it. The next step is
to create the linux kernel configuration (/usr/src/linux.config), this can be
achieved using "make config", "make menuconfig" or "make xconfig", my preferred
method is "make menuconfig" (for this you will need ncurses and ncurses devel
libraries). This is arguably the hardest step, there are hundreds options, which
can be categorized into two main areas: hardware support, and service support.
For hardware support make a list of hardware that this kernel will be running on
(i.e. P166, Adaptec 2940 SCSI Controller, NE2000 Ethernet card, etc.) and turn
on the appropriate options. As for service support you will need to figure out
which file systems (fat, ext2, minix ,etc.) you plan to use, the same for
networking (firewalling, etc.).
Once you have configured the kernel you need to compile it, the following
commands makes dependencies ensuring that libraries and so forth get built in
the right order, then cleans out any information from previous compiles, then
builds a kernel, the modules and installs the modules.
make dep #(makes dependencies)
make clean #(cleans out previous cruft)
make bzImage #(make zImage pukes if the kernel is to big, and 2.2.x kernels tend to be pretty big)
make modules #(creates all the modules you specified)
make modules_install #(installs the modules to /lib/modules/kernel.version.number/)
You then need to copy /usr/src/linux/arch/i386/boot/bzImage (or zImage) to
/boot/vmlinuz-kernel.version.number. Then edit /etc/lilo.conf, adding a new
entry for the new kernel and setting it as the default image is the safest way
(using the default=X command, otherwise it will boot the first kernel listed),
if it fails you can reboot and go back to the previous working kernel.
boot=/dev/hda
map=/boot/map
install=/boot/boot.b
prompt
timeout=50
default=linux
image=/boot/vmlinuz-2.4.9
label=linux
root=/dev/hda1
read-only
image=/boot/vmlinuz-2.4.5
label=linuxold
root=/dev/hda1
read-only
Once you have finished editing /etc/lilo.conf you must run /sbin/lilo to
rewrite the MBR (Master Boot Record). When LILO runs you will see output similar
to:
Added linux *
Added linuxold
It will list the images that are listed on the data in the MBR and indicate
with a * which is the default (typically the default to load is the first image
listed, unless you explicitly specify one using the default directive).
Kernel versions
Currently the stable kernel release series is 2.4.x, and the development
series is 2.5.x. The 2.3.x development series of kernels is not recommended,
there are many problems and inconsistencies. The 2.2.x series of kernel while
old and lacking some features is relatively solid, unfortunately the upgrade
from 2.2.x to 2.4.x is a pretty large step, I would advise caution. Several
software packages must be updated, libraries, ppp, modutils and others (they are
covered in the kernel docs / rpm dependencies / etc.). Additionally keep the old
working kernel, add an entry in lilo.conf for it as "linuxold" or something
similar and you will be able to easily recover in the event 2.2.x doesn't work
out as expected. Don't expect the 2.4.x series to be bug free, flaws will be
found and older versions will become obsolete, like every piece of software in
the world.
There are a variety of kernel level patches that can enhance the security of
a Linux system. Some prevent buffer overflow exploits, other provide strong
crypto.
Kernel patches
There are a variety of kernel patches directly related to security.
Secure Linux kernel patch
This patch solves a number of issues and provides another level of security
for the system. The patch is available for the 2.0 and 2.2 kernel series. You
can get it from: https://www.openwall.com/linux/.
International kernel patch
This patch (over a megabyte in size!) adds a huge amount of strong crypto and
related items. It includes several encryption algorithms that were AES
candidates (including MARS from IBM). You can get it from: https://www.kerneli.org/. https://sourceforge.net/projects/cryptoapi/
Linux Intrusion Detection System Patch (LIDS)
This patch adds a number of interesting capabilities, primarily aimed at
attack detection. You can "lock" file mounts, firewall rules, and a variety of
other interesting options are available. You can get it from: https://www.lids.org/
RSBAC
Rule Set Based Access Control is a comprehensive set of patches and utilities
to control various aspects of the system, from filesystem ACL's and up. You can
get it from: https://www.rsbac.de/rsbac/.
LOMAC
LOMAC (Low Water-Mark Mandatory Access Control for Linux) is a set of kernel
patches to enhance Linux security. You can get it at: ftp://ftp.tislabs.com/pub/lomac/.
auditd
auditd allows you to use the kernel logging facilities (a very powerful
tool). You can log mail messages, system events and the normal items that syslog
would cover, but in addition to this you can cover events such as specific users
opening files, the execution of programs, of setuid programs, and so on. If you
need a solid audit trail then this is the tool for you, you can get it at: ftp://ftp.hert.org/pub/linux/auditd/.
Fork Bomb Defuser
A loadable kernel module that allows you to control the maximum number of
processes per user, and the maximum number of forks, very useful for shell
servers with untrusted users. You can get it from: https://rexgrep.tripod.com/rexfbdmain.htm.
Debugging the Linux kernel
KDB v0.6 (Built-in Kernel Debugger)
An SGI kernel debugger, available at: https://oss.sgi.com/projects/kdb/.
kGDB (Remote kernel debugger)
SGI has written a tool that allows you to do kernel debugging, remotely which
is a big step up from being tied to the console. You can get it at: https://oss.sgi.com/projects/kgdb/.
