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.
More Articles by Tony Lawrence © 2009-11-07 Tony Lawrence
If you ask "Should we be in space?" you ask a nonsense question. We are in space. We will be in space. (Frank Herbert)
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..
------------------------
Printer Friendly Version
Hardening your Kernel with OpenWall Copyright © March 2005 Tony Lawrence
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
Printer Friendly Version