Written by Kurt Seifried
|
Документ взят из кэша поисковой машины. Адрес
оригинального документа
: http://www.arcetri.astro.it/irlab/doc/library/linux/lasg-www/kernel/index.html
Дата изменения: Tue Jan 18 09:28:00 2000 Дата индексирования: Sat Dec 22 15:22:49 2007 Кодировка: Поисковые слова: р п р п р п р п р п р п |
Upgrading and compiling the kernel
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 (we have had 0, 1 and 2 so far). I would highly recommend running kernel 2.2.x, as of December 1999 this is 2.2.13. 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 @linux.kernel.org:
[seifried@mail kernel-patches]$ finger @linux.kernel.org [linux.kernel.org] The latest stable version of the Linux kernel is: 2.2.13 The latest beta version of the Linux kernel is: 2.3.29 The latest prepatch (alpha) version *appears* to be: 2.3.30-3
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.2.9 label=linux root=/dev/hda1 read-only image=/boot/vmlinuz-2.2.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).
Currently the stable kernel release series is 2.2.x, and the development series is 2.3.x. The 2.1.x development series of kernels is not recommended, there are many problems and inconsistencies. The 2.0.x series of kernel while old and lacking some features is relatively solid, unfortunately the upgrade from 2.0.x to 2.2.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.2.x series to be bug free, 2.2.9 will be found to contain flaws and 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.
There are a variety of kernel patches directly related to security.
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: http://www.openwall.com/linux/.
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: http://www.kerneli.org/.
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: http://www.soaring-bird.com.cn/oss_proj/lids/.
The Linux trustees (ACL) project is a series of kernel patches and utilities to configure ACL access to the filesystem. This solution is still a bit klunky as it keeps the permissions in a file, and acts as a filtering layer between the file and the users, it isn’t actually a proper ACL enabled filesystem (but it is a start). You can get it at: http://www.braysystems.com/linux/trustees.html.
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: http://www.rsbac.de/rsbac/.
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 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/.
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: http://rexgrep.tripod.com/rexfbdmain.htm.
An SGI kernel debugger, available at: http://oss.sgi.com/projects/kdb/.
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: http://oss.sgi.com/projects/kgdb/.
| Written by Kurt Seifried |