Posts Tagged ‘Exec-Shield’

This past week I had a very stimulating discussion with a very talented co-worker of mine. This discussion was about Exec-Shield (DEP for all my Windows fans) and ASLR under RedHat. Through the course of this discussion, we discovered a very interesting script that helped us detect which of our running processes were protected by exec-shield as well as some nifty kernel tunables for exec-shield, and ASLR. Incidentally, he wrote a very informative article about it over at, you should check it out. Also he has a lot of other great nix sysadmin stuff there that is definitely worth your time.

Now you’re probably thinking. Hey DT what’s this got to do with Ubuntu, you’re talking about RedHat, what’s with the sensational title?

To that, I say. “Dear reader, you catch on fast. It has absolutely NOTHING to do with Ubuntu.” Therein lies our problem, for a server OS that Canonical touts as production ready with nifty slogans like “We are cloud.” I was somewhat astonished to find that exec-shield support in Ubuntu is rather limited (read nonexistant).

What is this exec-shield and why do I want it?

Exec-Shield also referred to as NX bit and DEP is a system designed for 64 Bit PAE (Physical Address Extension) systems to divide executable code into two sections, a .data section and the actual executable instructions. Basically this helps you mitigate stack, heap and int based overflows by mitigating the executability (is that a word?) of injected shell code. The overflow will still happen, however no payload execution happens. This is obviously a nice thing to have happening.

How do I know it’s enabled?

Well quite simply on a RHEL/CentOS/FC box if you do the following

sudo sysctl kernel.exec-shield

You will get some output that signifies what setting you have for exec-shield. Default is 1

kernel.exec-shield = 1

It should look like that. Really quick, a rundown on the possible values.

  • 0 – Disabled, regardless of whether the application is compiled to support it.
  • 1 – Enabled if the application is compiled to support it.
  • 2 – Enabled for all applications unless they are compiled without it.
  • 3 – Enabled regardless of what the application is compiled to support.

But what about Ubuntu? If you were following along with Ubuntu you likely got an error when you typed that command. Why is that you ask? Quite simply, your kernel does not support Exec-Shield.

Time to switch to RHEL?

Ideally, for production systems yes, for many reasons not just this, but it’s expensive (CentOS isn’t ;-)). That being said you know I love Ubuntu. So, I have an alternative solution for you.

Emulating Exec-Shield on Ubuntu

There are a couple of things to understand here before we start. Debian upstream and thus Ubuntu removed the exec-shield patch from the distribution a few years ago, claiming it was replaced by gcc’s compile time optimizations. There is a major flaw in this logic, these enforcements are made at the application level, which is a terrible place to have them made. The kernel level is much more suitable for this type of control. Incidentally, the two work wonderfully together.

We do not have access to exec-shield, however we can emulate it through grsec, which is exactly what we are going to be doing here.

Note : this involves recompiling your kernel, so breakage could ensue.

Note+ : You will also need build essential for this

sudo apt-get install build essential

Note++ : For make menuconfig we’ll also need ncurses-dev.

sudo apt-get install libncurses5-dev

Step 1 : Downloading grsec

The first step is to obtain the latest stable release of grsec.


Step 2 : Downloading Kernel Source

Next we need the kernel source, this has to be done with an unpatched kernel so we can not use our existing kernel source.


Once it’s downloaded extract your kernel source

tar xzvf linux-

Step 3 : Patching the kernel

Now we’ll patch our kernel source.

cd linux-
sudo su -
patch -p1 < ../grsecurity-2.2.2-

Step 4 : Configuring our patched Kernel

Now we run

make menuconfig

Most of the defaults are acceptable however we need to look at our “Security” Options








The first thing we’ll look at is GRSecurity. There are a variety of options in here. You will need to explore the ones that fit your needs best. However I recommend enabling the following

  • Security Level High
  • Hide /proc from users
  • Sysctl Support On
  • Enable Features by default On

There are many more tunables that you can fiddle with here.

There are also quite a few tunables under PaX that can be adjusted here however, the defaults are quite acceptable.








Once you’re done making changes we’re ready to compile the kernel.

Step 5 : Compiling our Grsecurity Kernel

For non-Ubuntu distros (since this has been pretty generic up until this point) we can simply


Alternatively for Ubuntu users we can build our kernel in the Debian method by doing the following.

make-kpkg clean
sed -rie 's/echo "\+"/#echo "\+"/' scripts/setlocalversion
rm localversion-grsec
fakeroot make-kpkg --initrd kernel_image kernel_headers

Note : If you follow this step you may simply use dpkg -i to install your new kernel. Users following the other method should update their grub config and install the kernel in the normal method.

After Kernel Installation

Once we have our GRSecurity enabled kernel installed we can use the gradmn tool to put GRSecurity in learning mode and create a policy which will be enforced.
You can learn more about doing that here.
Once you have done this your Ubuntu server will be much more ready for production usage. Though…Installing CentOS takes far less time 😉