Hardening your Kernel with OpenWall

March 2005

The Openwall Project provides security related kernel patches for Linux and BSD kernels. I read about this in Hardening Linux by James Turnbull. The patch that most interested me was to prevent executable code from running in the stack. That won't prevent all buffer overflow attacks, but it can stop some of them. I really don't understand why this isn't just the default nowadays - I know it can break some programs and debuggers, but it seems smart to me.

I installed this on a RedHat ES system. That system was running a 2.4.21 kernel, and had never installed kernel source, so the first step was to go get a newer kernel. I cd'd to /usr/src and did a

 cd /usr/src
 get ftp://ftp.kernel.org/pub/linux/kernel/v2.4/linux-2.4.29.tar.gz
 tar zxvf linux-2.4.29.tar.gz
 ln -s linux-2.4.29  linux
 wget http://www.openwall.com/linux/linux-2.4.29-ow1.tar.gz
 cp cp linux-2.4.29-ow1/*diff .
 patch -p0 < linux-2.4.29-ow1.diff
 

This patched the 2.4.29 kernel with the Openwall enhancements. I then copied the existing RedHat kernel config file so that I wouldn't have to answer a zillion questions (most of which I probably wouldn't have half a clue how to answer).

cd /usr/src/linux
cp /boot/config-2.4.21-27.0.2.EL /usr/src/linux/.config
make oldconfig
 

This did leave me with a few questions to answer for things new in the 29 kernel. I took the defaults until it got to the Openwall stuff. I then answered "y" for hardening the stack, but not for GCC trampolines because that's apparently for older 2.0 kernels. I also said "n" to the "Destroy shared memory segments" because of warnings in the FAQ that it can break some apps and the advice of the "Hardening Linux" book. I probably don't have anything here that would break, but I left it "n". This ended up with these settings:

CONFIG_HARDEN_STACK=y
# CONFIG_HARDEN_STACK_SMART is not set
CONFIG_HARDEN_LINK=y
CONFIG_HARDEN_FIFO=y
CONFIG_HARDEN_PROC=y
CONFIG_HARDEN_RLIMIT_NPROC=y
# CONFIG_HARDEN_SHM is not set
 

I then ran the typical "make dep" etc. and after a long, long wait everything completed and I ran "make install". That broke, complaining

grubby fatal error: unable to find a suitable template
 

Grubby? I had never heard of it, but "man" showed me that it is used to update /etc/lilo.conf or /etc/grub.conf. The man page mentioned templates, but didn't explain enough to tell me what its problem might be. However, looking in /boot, I could see that everything I needed had been installed there, so I went ahead and edited /etc/grub.conf by hand. Unfortunately, I fat fingered it and ended up with this:

# NOTICE:  You have a /boot partition.  This means that
#          all kernel and initrd paths are relative to /boot/, eg.
#          root (hd0,0)
#          kernel /vmlinuz-version ro root=/dev/hda2
#          initrd /initrd-version.img
#boot=/dev/hda
default=0
timeout=10 
splashimage=(hd0,0)/grub/splash.xpm.gz 

title Red Hat Enterprise Linux ES (2.4.29-ow1)
root (hd0,0)/grub 
kernel (hd0,0)/vmlinuz-2.4.21-27.0.2.EL ro root=/dev/hda2 hdb=ide-scsi
initrd (hd0,0)/initrd-2.4.29-ow1.img

title Red Hat Enterprise Linux ES (2.4.21-4.EL)
root (hd0,0)/grub 
kernel (hd0,0)/vmlinuz-2.4.29-ow1 ro root=/dev/hda2 hdb=ide-scsi
initrd (hd0,0)/initrd-2.4.21-27.0.2.EL.img
 

Do you see the mistake? It should have looked like this:

# NOTICE:  You have a /boot partition.  This means that
#          all kernel and initrd paths are relative to /boot/, eg.
#          root (hd0,0)
#          kernel /vmlinuz-version ro root=/dev/hda2
#          initrd /initrd-version.img
#boot=/dev/hda
default=0
timeout=10 
splashimage=(hd0,0)/grub/splash.xpm.gz 

title Red Hat Enterprise Linux ES (2.4.29-ow1)
root (hd0,0)/grub 
kernel (hd0,0)/vmlinuz-2.4.29-ow1 ro root=/dev/hda2 hdb=ide-scsi
initrd (hd0,0)/initrd-2.4.29-ow1.img

title Red Hat Enterprise Linux ES (2.4.21-4.EL)
root (hd0,0)/grub 
kernel (hd0,0)/vmlinuz-2.4.21-4.EL ro root=/dev/hda2 hdb=ide-scsi
initrd (hd0,0)/initrd-2.4.21-27.0.2.EL.img
 

That gave me a lovely "file not found" when I attempted to boot. Not quite realizing what I had done, I then tried to boot the second kernel, and of course that failed with the same error. Looking more closely, I spotted my problem and used the "edit" capability of grub to point it at the right kernel.

That got me back up again. Openwall includes the source code for a program to test the stack changes, so I compiled that and tried it out:

cd /usr/src/linux-2.4.29-ow1/optional
gcc -o stacktest stacktest.c
./stacktest -e
Attempting to simulate a buffer overflow exploit...
Segmentation fault
 

I still haven't found out what template is needed for grubby, but I did find a patch for it: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=83512

Click here to add your comments




Fri Mar 4 17:05:21 2005: Subject:   TonyLawrence


I couldn't find anything on the web, so I went to the source:

# rpm -qf `which grubby`
mkinitrd-3.5.13-1

The source RPM happened to be on the first cd I looked at, and after unpacking it, I see that grubby actually looks at the existing grub.conf and apparently is getting confused about something.. haven't figured out what yet..



Don't miss responses! Subscribe to Comments by RSS or by Email

Click here to add your comments

If you want a picture to show with your comment, go get a Gravatar

Take Control of Upgrading to Snow Leopard

Take Control of Exploring & Customizing Snow Leopard

Jump to Comments

Many of the products and books I review are things I purchased for my own use. Some were given to me specifically for the purpose of reviewing them. I resell or can earn commissions from the sale of some of these items. Links within these pages may be affiliate links that pay me for referring you to them. That's mostly insignificant amounts of money; whenever it is not I have made my relationship plain. I also may own stock in companies mentioned here. If you have any question, please do feel free to contact me.

Specific links that take you to pages that allow you to purchase the item I reviewed are very likely to pay me a commission. Many of the books I review were given to me by the publishers specifically for the purpose of writing a review. These gifts and referral fees do not affect my opinions; I often give bad reviews anyway.

We use Google third-party advertising companies to serve ads when you visit our website. These companies may use information (not including your name, address, email address, or telephone number) about your visits to this and other websites in order to provide advertisements about goods and services of interest to you. If you would like more information about this practice and to know your choices about not having this information used by these companies, click here.