crazylazy.info

txt

Setting up the server

If you do this, you want three things:

• a clean and secure setup, that ensures your availability - even if you're working on a remote-server
• easy steps
• drinking a coke or a coffee during this setup. No beer. Because kernel-upgrades and beer don't work together

Okay, what's grsecurity and why do I need it

Easily said: it's doing everything to prevent successful exploitation, like we recently saw happening on Linux through SCTP, ptrace or UDEV.
The sctp-Exploit (a masterpiece) in the end is a simple memory corruption - so to counter we could need memory-protection. The other two code-pireces force privilege escalations and probably aren't the best examples. Nevertheless most exploits today are just buffer-overruns - that's almost boring.
- In order to protect bad application-code from bad exploit-code modern operating systems can implement certain layers of security measurements to prevent successful exploitation. Like memory address space layout randomization - to just shake the addresses in memory into organized chaos; or access-levels combined with user separation - mainly to ensure information integrity.

If in address-space - where the variables are stored (data or bss segment) - overwriting the buffer-space doesn't affect the one running process, successful exploitation-strategies need to include guessing where the vulnerable buffers are. Which is possible too, but I guess the random script-kiddie cannot do this. It's getting harder to exploit applications. Now with:

• RBAC
• memory protection features
• Segmentation-based implementation of non-executable user pages for i386 with no performance hit
• Randomization of stack and mmap base
• ... a lot more

If you like this stuff, have a look at this setup, which focuses Debian because it's on many servers. Unless you aren't sure you need that level of security, don't install. Or consult knowing people. It's a little... dangerous because you cannot know about the compatibility issues.

Installation procedure

I like to keep it minimal: Don't use a kernel-source > 2.6.29.3.

Now unpack that stuff. Create a softlink that links /usr/src/linux to it.

And verfiy like "gpg --verify file.sig file", because the .sig is there too.

Let's patch that source now with all these fancy features, while we are in /usr/src/linux/ :

Now let's make the kernel. Unless you've no special config, you don't need to copy it into your actual building folder.

In the menu now you're able to chose what you want. If you ask me: don't play around with stuff you don't understand unless you've got local access to that box. Or you really know what you're doing. There're predefined configs: a normal server should run pretty good in "Medium". I like "High". Don't be a low hanging fruit ;).

After the configuration screen you'll need your tea or coffee. Because even modern systems need some time to compile operating system kernels. Did you ever try Earl Grey with milk and sugar? Tastes wonderful - especially together with nice manuals.

After the build is ready, use "dpkg -i" for the two new .debs in /usr/src.

The next thing to to is to run "apt get update" and "apt-get upgrade" - just for fun - before you're updating your bootloader configuration. I found out that apt-get tends to overwrite the menu.lst in case of Grub:

In that case that would be two for default, because it starts counting with 0. In case something doesn't work the system will fallback to one - a kernel that just works. Any experiments with configurations therefore should be safe.

And reboot your box. The rest is pretty well documented. It just works. Here's the PaXtest on a medium secured Debian:

Mode: blackhat
Linux kaze.crazylazy.info 2.6.27.10-grsec #1 SMP Tue May 26 19:11:15 CEST 2009 i686 GNU/Linux

Executable anonymous mapping : Killed
Executable bss : Killed
Executable data : Killed
Executable heap : Killed
Executable stack : Killed
Executable anonymous mapping (mprotect) : Vulnerable
Executable bss (mprotect) : Vulnerable
Executable data (mprotect) : Vulnerable
Executable heap (mprotect) : Vulnerable
Executable shared library bss (mprotect) : Vulnerable
Executable shared library data (mprotect): Vulnerable
Executable stack (mprotect) : Vulnerable
Anonymous mapping randomisation test : 18 bits (guessed)
Heap randomisation test (ET_EXEC) : 13 bits (guessed)
Heap randomisation test (ET_DYN) : 24 bits (guessed)
Main executable randomisation (ET_EXEC) : No randomisation
Main executable randomisation (ET_DYN) : 16 bits (guessed)
Shared library randomisation test : 18 bits (guessed)
Stack randomisation test (SEGMEXEC) : 24 bits (guessed)
Stack randomisation test (PAGEEXEC) : 24 bits (guessed)
Return to function (strcpy) : Vulnerable
Return to function (strcpy, RANDEXEC) : Vulnerable
Return to function (memcpy) : Vulnerable
Return to function (memcpy, RANDEXEC) : Vulnerable
Executable shared library bss : Killed
Executable shared library data : Killed
Writable text segments : Vulnerable

Note that some of the "Vulnerable" _features_ are needed for compatibility. It's of course arguable, but poeple taking security seriously are rare. After some configs you'll beat this test, for sure ;).

Have fun,
wishi