///Hardening your Kernel with OpenWall

Hardening your Kernel with OpenWall

Hardening your Kernel with OpenWall

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

2010-05-26T11:22:14+00:00 May 12th, 2005|Linux|0 Comments

About the Author:

Leave A Comment