Grsecurity/Configuring and Installing grsecurity
The following instructions will lead you through the process of patching the Linux kernel with grsecurity, configuring its features and compiling, and installing the patched kernel.
Patching Your Kernel with grsecurity
In this document the compressed kernel source package is called ‘’linux-3.2.21.tar‘’ and the matching grsecurity patch ‘’grsecurity-2.9.1-3.2.21-201206201812.patch'’. Both files are in the same directory.
Change to the root user and run the following commands in the directory you downloaded the files to. The first command decompresses the Linux source package, and the second one applies the patch to the kernel.
# tar -xf linux-3.2.21.tar # cd linux-3.2.21 # patch -p1 < ../grsecurity-2.9.1-3.2.21-201206201812.patch
Configuring the Kernel
The kernel source package contains a generic configuration file that should work without any significant modifications. Your distribution may have its own process and tools for configuring and building the kernel, in which case you should consult their documentation. Nonetheless you should go through the options and make sure they match your hardware and current setup.
To configure the kernel using the default configuration as a base, change into the kernel source directory (e.g. ‘’/usr/src/linux-3.2.21‘’), and execute the below command.
$ make menuconfig
In the 2.6 kernels, the grsecurity options are under Security options » Grsecurity. In the 2.4 kernels there is a top-level menu item called Grsecurity. Use the built-in help of the kernel configuration system, and make sure you understand each option before you enable or disable them.
There are three basic security levels—low, medium and high—and a custom level for advanced users. You should choose one of the basic the security levels that best suits your situation. See the Appendix for a list of all grsecurity and PaX kernel configuration options and their descriptions. You can use it to plan ahead what features to enable.
- Enable the sysctl interface (Grsecurity » Sysctl support). It will enable you to change the options that grsecurity runs with without recompiling the kernel. This is a very helpful feature especially when you are using grsecurity for the first time.
- Some auditing options produce a lot of log messages, most notably exec and chdir logging (GRKERNSEC_EXECLOG and GRKERNSEC_AUDIT_CHDIR, respectively). If you enable either of them, make sure your logging system is properly configured to prevent the logs from flooding.
Compiling and Installing the Kernel
On Debian and Ubuntu
To compile the kernel and build a Debian package (deb), execute the below commands in the kernel source directory. Ubuntu users should reference the Ubuntu Community Page and decide whether they wish to use the ubuntu-package overlay directory in building. For building on Maverick from a git checkout, see How to compile a Ubuntu 10.10 kernel
# fakeroot make deb-pkg
To install the newly created Debian package, run:
# cd .. # dpkg -i *.deb
For more information about building kernels in Debian, please refer to the Debian Linux Kernel Handbook.
- Gentoo Linux: Gentoo Linux (x86) Handbook and Hardened Gentoo
- CentOS: http://wiki.centos.org/HowTos/Custom_Kernel
- Fedora (release 8 and later): http://fedoraproject.org/wiki/Docs/CustomKernel
As you are compiling a kernel patched with grsecurity, you will notice some differences. One of these differences appears towards the end of compilation, and may look similar to:
WARNING: modpost: Found 2820 section mismatch(es). To see full details build your kernel with: ‘make CONFIG_DEBUG_SECTION_MISMATCH=y'
This warning is harmless. As described by the PaX Team on the grsecurity mailing list:
the extra section mismatches are due to my changes, i explicitly added detection for writeable function pointers which are potential exploit targets, just to know how many of them there are. we’ve been eliminating some of them already but this work will never finish. as for what they are in general, a mismatch means an unwanted reference from one section to another. say, accessing init code or data from normal code/data is not good since init sections are freed up on boot, so any reference to them must not exist from permanent sections.
You will also notice additional warnings emitted by the compiler when compiling a kernel patched with grsecurity. This is due to additional warning flags that have been added to the build process to help spot specific kinds of bugs. You can ignore these additional warnings.