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 https://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

Got something to add? Send me email.

1 comment

Fri Mar 4 17:05:21 2005: 106   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..





------------------------

Have you tried Searching this site?

This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more.

Contact us