Hardened/Introduction to Hardened Gentoo
A Primer on Hardened Gentoo.
This guide is meant for anyone unsure about the offerings of the Hardened Gentoo project, how to use them together, and what their respective roles in the project are.
The basic security principle that we emphasize is layers of security. Layers are fundamental in ensuring a users machine is not compromised, and if it is, minimizing the damages done. By combining a series of dissimilar, though security related technologies, we make an attacker jump through additional hoops before a compromise may occur. For this reason we always recommended that you decide what your specific needs are and combine those solutions to protect your system. We will try to explain the options and how they can be used together in this document.
Hardened Gentoo is not a product or solution in itself, it is merely a project with a group of developers all working toward the same goal of very proactive security. The sub-projects contained in Hardened Gentoo aren't related in any more way than they are hosted within the same project. You might think of it as the same way KDE and GNOME are both part of the desktop project, and both have a common goal but are otherwise unrelated to each other.
Asking for help installing or support of your 'Hardened Gentoo' machine is not clear and should always be clarified by saying you have a SELinux problem, PIE/SSP problem, and so on.
At the heart of the project is PaX. PaX is a kernel patch that allows you to protect against buffer and heap overflows and similar attacks. PaX is your first line of defense.
Because of badly written software you are always at risk of a compromise because of buffer and heap overflows. Buffer and Heap overflows are the result of unchecked bounds in user input in applications. When an attacker has the ability to give input to an application that is inserted into memory but not checked there exists the possibility of an overflow. Lower level programming languages like C and C++ do not automatically protect from overruns, and the end result is that when a buffer is overrun adjacent executable code can be overwritten with input from the user. This would normally cause the application to crash if the users input isn't understood by the machine. This generally manifests itself as a page fault because the characters that overrun the buffer into the executable area will be treated as an address which probably won't exist. This is the most benign result of an overrun.
If the attacker knows of an overrun, however, they will have the opportunity to add shellcode to the input and rather than causing the application to crash it will instead execute the instructions they give. This is done because shellcode is how instructions are stored in memory for execution by the processor. Basically shellcode consists of 'opcodes' which translate to assembly routines. An attacker knows these opcodes very well and can create shellcode which allows them to do anything they desire, such as run a root shell and bind it to a port. When this happens the user won't even be aware that it has because the application doesn't crash, instead it starts executing the attackers arbitrary code allowing them to do anything they please. PaX mitigates this problem by randomly placing each function and buffer in an application in memory. This is called ASLR or Address Space Layout Randomization and is the cornerstone of PaX By having random offsets for functions and buffers the attacker is unable to craft an input which will guarantee that the shellcode will be executed (and makes it very difficult since the application will probably crash and be restarted with new random offsets). ASLR is most useful when used with PIE (position independent executable) code but also works with standard executable code, at the cost of overhead.
PaX also offers the ability for executable segments to be executable and not writable, and likewise writable segments to be writable and not executable. This is called pageexec. On x86 based processors there is no ability to do this on a hardware level since the x86 designers collapsed the read and execute memory flags into 1 to save space. Since a page can either be writable or readable and executable it is not useful to set buffers as non-executable since they would no longer be readable. So on x86 PaX emulates this behavior at a software level, which introduces overhead but is very helpful for security.
For more information, please see our PaX Quickstart document.
In the interest of clarity, while PIE and SSP are generally grouped in discussion because they are both part of the hardened toolchain, they are indeed different technologies with different purposes. PIE by itself provides no additional security, but when combined with PaX in the kernel provides a powerful tool against overflows. SSP is entirely implemented in userland and protects against stack smashing attacks without the assistance of the kernel. Since these are implemented separately and do different things they are indeed 2 different layers of protection, for example, one attack that might get past PaX, called ret2libc, would be blocked by SSP.
We have gone through great lengths to provide users with an easy way to build the entire userland with PIE code as to take advantage of ASLR with very little overhead. In addition to PIE our 'hardened' toolchain also provides SSP or stack smashing protection. SSP protects against stack smashing by allocating an area outside of buffers and putting a random, cryptographic canary (or marker) in it. This allows SSP to check whether the canary was overwritten after any write to the buffer and allows it to kill the app if it was overwritten. The hardened toolchain gives users a PIE/SSP userland the easiest possible way. Stages marked with 'hardened' are standard stages built with PIE and SSP, they do not include SELinux/RSBAC/grsecurity access controls.
grsecurity kernel patches
Although PaX is part of the grsecurity patch set, the grsecurity project has a lot more kernel improvements to offer than just PaX. Its features are broad, and focuses on a large set of risk mitigations to prevent memory-oriented attacks from being effective. It includes more sanity checks on memory copies, stack overflow preventions, hardened memory permissions, memory address randomization, detection and reaction against bruteforce attacks, enhanced chroot protections, trusted path execution and much, much more.
The sys-kernel/hardened-sources package is the kernel package of choice if you want grsecurity based protections on your system. Be sure to read the documentation available on our wiki as well as on the grsecurity project site for the instructions on how to enable and work with those protection measures.
Mandatory Access Control
While PaX is the first layer of protection, perhaps even the second or third if you have firewalls and/or network intrusion detection, it is also recommended that you use access control to further secure your system. It is very important that you realize access control as your last layer of protection. Access control is very helpful to contain attackers which already got access to your system, or local users. Currently Hardened Gentoo supports 3 access control solutions: SELinux, grsecurity, and RSBAC.
If you wish to use grsecurity you need not worry about which stages to use as grsecurity requires no userland changes. Simply use the hardened stages and once you are ready to build a kernel use a grsecurity-enabled kernel such as hardened-sources. Once your system is up and running you can use grsecurity's learning mode to build ACL's for your system.
Similar to grsecurity, RSBAC does not require any userland changes but can be installed after setting up a normal Gentoo installation. RSBAC is supported by the rsbac-sources kernel. Once your system is running you can then choose from the different access control models offered by RSBAC since they are all modules. The RSBAC Gentoo documentation lists the various models offered and provides more information about each one.
For more information about Gentoo's SELinux support, please see the SELinux portal page.
Linux Integrity Measurement Architecture
The Integrity Measurement Architecture is a mainly Linux kernel driven security subsystem which focuses on the validation of file integrity before these files are loaded (and perhaps executed). It does so by comparing the hash of the file with a stored hash and only allowing the loading of that file to memory if the hashes match. The technology is specifically designed for preventing offline tampering of data: either the hash is cryptographically secure, ensuring that no-one can generate the same hash without access to a private key, or the validation is done remotely (called remote attestation) where the remote side checks the measured hashes against its own list. The latter situation could be used to only allow clients to access a VPN network if they can prove they have not been tampered with.
Alongside IMA is the Extended Verification Module (EVM) subsystem, which provides protection against tampering the hashes themselves, as well as tampering other extended attributes of files, such as SELinux' extended attributes). Together, these technologies play an important role in Linux' adoption of the Trusted Computing Base, interacting with specially designed security devices on systems (such as the Trusted Platform Module or TPM chip).
So we've talked about the various technologies and security layers that we offer; we have intentions to offer more and will in the future. Examples of additional layers are intrusion detection/prevention, which would be first even before PaX. Encrypted disks and swap which offer protection from 'physical' security breaches. Auditing, which would allow you to see and act upon risks before they become a compromise. Encrypted network traffic and strong authentication are also layers which are very supported in mainline Linux installations and probably won't be focused upon here.
|Project||Project homepage||Gentoo project page|
|PIE||Not Available||Not Available|
This article is based on a document formerly found on our main website gentoo.org.
The following people have contributed to the original document: Joshua Brindle, Adam Mondl, Ned Ludd
They are listed here as the Wiki history does not provide for any attribution. If you edit the Wiki article, please do not add yourself here, your contributions are recorded on the history page.