This document features the grsecurity 2.x security patches, supported kernel configuration options and tools provided by the grsecurity project to lift your system's security to higher standards.
- 1 About Grsecurity
- 2 PaX
- 3 RBAC
- 4 Filesystem Protection
- 5 Kernel Auditing
- 6 Process Restrictions
- 7 The Hardened Toolchain
- 8 Resources
- 9 Acknowledgements
The Grsecurity Project
The grsecurity project, hosted on http://www.grsecurity.org , provides various patches to the Linux kernel which enhance your system's overall security. The various features brought by grsecurity are discussed in the next chapter; a comprehensive list is maintained on the grsecurity features page itself.
As grsecurity's features are mostly kernel-based, the majority of this document explains the various kernel features and their respective sysctl operands (if applicable).
Gentoo Hardened Integration
The Gentoo Hardened Project maintains security-enhancement features for Gentoo, including but not limited to grsecurity.
Throughout this document we will talk about kernel configuration using the kernel variables like
CONFIG_GRKERNSEC_PAX_NO_ACL_FLAGS . These are the variables that the kernel build process uses to determine if a certain feature needs to be compiled.
When you configure your kernel through
make menuconfig or similar, you receive a user interface through which you can select the various kernel options. If you select the Help button at a certain kernel feature you will see at the top that it lists such a kernel variable.
You can therefore still configure your kernel as you like - with a bit of thinking. And if you can't find a certain option, there's always the possibility to edit /usr/src/linux/.config by hand :)
Of course, to be able to select the various grsecurity kernel options, you must enable grsecurity in your kernel:
Fighting the Exploitation of Software Bugs
PaX introduces a couple of security mechanisms that make it harder for attackers to exploit software bugs that involve memory corruption (so don't treat PaX as if it protects against all possible software bugs). The PaX introduction document talks about three possible exploit techniques:
- introduce/execute arbitrary code
- execute existing code out of original program order
- execute existing code in original program order with arbitrary data
One prevention method disallows executable code to be stored in writable memory. When we look at a process, it requires five memory regions:
- a data section which contains the statically allocated and global data
- a BSS region (Block Started by Symbol) which contains information about the zero-initialized data of the process
- a code region , also called the text segment , which contains the executable instructions
- a heap which contains the dynamically allocated memory
- a stack which contains the local variables
The first PaX prevention method, called NOEXEC , is meant to give control over the runtime code generation. It marks memory pages that do not contain executable code as non-executable. This means that the heap and the stack, which only contain variable data and shouldn't contain executable code, are marked as non-executable. Exploits that place code in these areas with the intention of running it will fail.
NOEXEC does more than this actually, interested readers should focus their attention to the PaX NOEXEC documentation .
The second PaX prevention method, called ASLR (Address Space Layout Randomization), randomize the addresses given to memory requests. Where previously memory was assigned contiguously (which means exploits know where the tasks' memory regions are situated) ASLR randomizes this allocation, rendering techniques that rely on this information useless.
More information about ASLR can be found online .
The recommended kernel setting for PaX is:
If you are running a non-x86 system you will observe that there is no CONFIG_GRKERNSEC_PAX_NOEXEC. You should select CONFIG_GRKERNSEC_PAX_PAGEEXEC instead as it is the only non-exec implementation around.
Not all Linux applications are happy with the PaX security restrictions. These tools include xorg-x11, java, mplayer, xmms and others. If you plan on using them you can elevate the protections for these applications using
chpax provides an init script that handles most known application settings for you:
pax-utils is a small toolbox which contains useful applications to administrate a PaX aware server.
Interesting tools include
scanelfyou can scan over library and binary directories and list the various permissions and ELF types that pertain to running an ideal pax/grsec setup
pspaxyou can display PaX flags/capabilities/xattr from the kernel's perspective
Verifying the PaX Settings
Peter Busser has written a regression test suite called
paxtest . This tool will check various cases of possible attack vectors and inform you of the result. When you run it, it will leave a logfile called paxtest.log in the current working directory.
In the above example run you notice that:
- strcpy and memcpy are listed as Vulnerable . This is expected and normal - it is simply showing the need for a technology such as ProPolice/SSP
- there is no randomization for PAGEEXEC. This is normal since our recommended x86 kernel configuration didn't activate the PAGEEXEC setting. However, on arches that support a true NX (non-executable) bit (most of them do, including x86_64), PAGEEXEC is the only method available for NOEXEC and has no performance hit.
Role Based Access Control
There are two basic types of access control mechanisms used to prevent unauthorized access to files (or information in general): DAC (Discretionary Access Control) and MAC (Mandatory Access Control). By default, Linux uses a DAC mechanism: the creator of the file can define who has access to the file. A MAC system however forces everyone to follow rules set by the administrator.
The MAC implementation grsecurity supports is called Role Based Access Control. RBAC associates roles with each user. Each role defines what operations can be performed on certain objects. Given a well-written collection of roles and operations your users will be restricted to perform only those tasks that you tell them they can do. The default "deny-all" ensures you that a user cannot perform an action you haven't thought of.
Configuring the Kernel
The recommended kernel setting for RBAC is:
Working with gradm
gradm is a tool which allows you to administer and maintain a policy for your system. With it, you can enable or disable the RBAC system, reload the RBAC roles, change your role, set a password for admin mode, etc.
When you install
gradm a default policy will be installed in /etc/grsec/policy :
By default, the RBAC policies are not activated. It is the sysadmin's job to determine when the system should have an RBAC policy enforced and not Gentoo's. Before activating the RBAC system you should set an admin password.
To disable the RBAC system, run
gradm -D . If you are not allowed to, you first need to switch to the admin role:
If you want to leave the admin role, run
gradm -u admin :
Generating a Policy
The RBAC system comes with a great feature called "learning mode". The learning mode can generate an anticipatory least privilege policy for your system. This allows for time and money savings by being able to rapidly deploy multiple secure servers.
To use the learning mode, activate it using
Now use your system, do the things you would normally do. Try to avoid rsyncing, running locate of any other heavy file i/o operation as this can really slow down the processing time.
When you believe you have used your system sufficiently to obtain a good policy, let
gradm process them and propose roles under /etc/grsec/learning.roles :
Audit the /etc/grsec/learning.roles and save it as /etc/grsec/policy (mode 0600) when you are finished.
You will now be able to enable the RBAC system with your new learned policy.
Tweaking your Policy
An interesting feature of grsecurity 2.x is Set Operation Support for the configuration file. Currently it supports unions, intersections and differences of sets (of objects in this case).
Here is an example of its use, and the resulting objects that will be added to your subject:
The above would expand to:
This is the result of the & operator which takes both sets and returns the files that exist in both sets and the permission for those files that exist in both sets.
This example would expand to:
This is the result of the | operator which takes both sets and returns the files that exist in either set. If a file exists in both sets, it is returned as well and the mode contains the flags that exist in either set.
This example would expand to:
This is the result of the - operator which takes both sets and returns the files that exist in the set on the left but not in the match of the file in set on the right. If a file exists on the left and a match is found on the right (either the filenames are the same, or a parent directory exists in the right set), the file is returned and the mode of the second set is removed from the first set, and that file is returned.
In some obscure pseudo-language you could see this as:
As for order of precedence (from highest to lowest): "-, & |".
If you do not want to bother remembering precedence, parenthesis support is also included, so you can do things like:
Fighting Chroot and Filesystem Abuse
Grsecurity2 includes many patches that prohibits users from gaining unnecessary knowledge about the system. This includes restrictions on /proc usage, chrooting, linking, etc.
We recommend the following grsecurity kernel configuration for filesystem protection:
Triggering the Security Mechanism
When you're using a kernel compiled with the above (or similar) settings, you will get the option to enable/disable many of the options through the /proc filesystem or via
The example below shows an excerpt of a typical /etc/sysctl.conf :
You can enable or disable settings at will using the
Toggling the exec_logging feature ON
Toggling the exec_logging feature OFF
There is a very important sysctl setting pertaining to grsecurity, namely
kernel.grsecurity.grsec_lock . When set, you are not able to change any setting anymore.
Extend your System's Logging Facilities
grsecurity adds extra functionality to the kernel pertaining the logging. With grsecurity's Kernel Auditing the kernel informs you when applications are started, devices (un)mounted, etc.
The various Kernel Audit Settings
The following kernel configuration section can be used to enable grsecurity's Kernel Audit Settings:
With grsecurity you can restrict executables. Since most exploits work through one or more running processes this protection can save your system's health.
Linux' TCP/IP stack is vulnerable to prediction-based attacks. grsecurity includes randomization patches to counter these attacks. Apart from these you can also enable socket restrictions, disallowing certain groups network access alltogether.
The following kernel settings enable various executable and network protections:
The Hardened Toolchain
Although it is outside the scope of this document we mention the use of the hardened toolchain which completes the grsec/PaX model from userspace.
- Grsecurity Homepage
- Grsecurity Forums
- Increasing Performance and Granularity in Role-Based Access Control Systems
- Capability Names and Descriptions
- Grsecurity Quick-Start Guide (NEW .pdf)
- Using PaX with Gentoo QuickStart (NEW)
- Grsecurity with Gentoo 1.9.x MAC system (OLD)
- PaX: The Guaranteed End of Arbitrary Code Execution
- PaX HomePage and Documentation
We would like to thank the following authors and editors for their contributions to this guide:
- Ned Ludd
- Sven Vermeulen