Hardened Gentoo: description

To begin, tell you why I am publishing this article. The fact is that most Gentoo Linux users still do not use Hardened Gentoo . And it is usually caused by the fact that they either do not know what it is, or they think that it is too difficult, or they believe that stability, functionality or system performance will suffer from it. These are the concerns I want to try to dispel.

Hardened Gentoo is a few changes in the compiler and the kernel, which increase the overall security of the system against hacking. For example, the hardened-core can block a lot of potentially dangerous operations, and hardened-gcc protects the programs compiled by it from hacking by standard methods a la buffer overflow. Roughly speaking, if you have a leaky version of program X, and a hacker tries to crack it, then in the usual system it will succeed, but in the hardened it will not work, and the record will go to the log as well.

To install Hardened on a regular Gentoo, you will need to completely recompile the entire system - otherwise the protection provided by hardened-gcc will not be used. Hardened is another system that needs to be carefully tuned - you overdo it with security - nothing will work at all, you don’t want to - why should you put Hardened at all? Some hardened programs do not get along (usually binary packages: firewood nVidia / ATI, Java plus for some reason software like mplayer / xmms) is not fatal, you just have to disable some of the protections for these progs (there are utilities for this) ... which grieves. The kernel is used from the hardened-sources package, and it usually lags behind gentoo-sources for a couple of versions.

So, Hardened Gentoo is just a union of several different, often independent from each other, projects:

1. Hardened toolchain - special gcc / glibc / binutils patches:
   
   • SSP - adds buffer overflow protection to the binary, i.e. the prog compiled with SSP itself checks that it does not overflow the buffer and wags itself if it detects an overflow (as a result of a bug in the program itself or an attempt to crack it with an exploit).
   • PIE does not increase security by itself, but leads to the generation of more flexible code, so that it can be protected at the kernel level through PaX.
   
   PIE and SSP are independent of each other, and they can be used together and separately (after compiling the hardened toolchain, it will be possible to switch between all options via gcc-config - PIE + SSP, only PIE, only SSP, nothing (i.e., normal gcc) - for example, if some kind of prog will not compile.
2. Patches to the core. There are a lot of them, and different, :) but Gentoo has support for only four of them - PaX , SeLinux , GrSecurity and RSBAC . They add three types of functionality:
   
   1. Protection against buffer overflow (a la SSP but from the kernel and other methods, so that they complement each other): PaX. For example, PaX allows you to prohibit code execution in data memory pages (software implementation of NX-bits, which appeared only in Intel 64-bit processes) - PaX will simply kill the process if it tries to violate this protection; when a program is loaded into memory, it loads all its functions at random addresses, so that the exploit is very difficult to know to which address to transfer control (this becomes possible due to compilation with PIE).
   2. Disabling potentially dangerous "features" of the kernel: GrSecurity, RSBAC. Example: the prohibition to execute mount inside chroot - so that a hacker hacked into a chroot daemon and obtained as root could not exit the chroot.
   3. Restriction of the rights of processes and users, including (I would even say - mostly) user root: SeLinux, GrSecurity / RBAC, RSBAC. Here the idea is that the admin (you :)) need to prepare a list indicating what programs / users that they have the right to do. Example: you can restrict the apache root process from all root rights to the opportunity to sit on port 80 and read the files in / etc / apache2 /. In this case, even if it is hacked, and the hacker gets “root”, THIS “root” can only do the above operations ... the hacker will be extremely disappointed. :)
   
   These three "features" are also not dependent on one another. But the patches themselves - SeLinux, GrSecurity and RSBAC are usually not compatible with each other and only one of them should be used. However, Gentoo managed to combine SeLinux and GrSecurity together. The part of GrSecurity which deals with the third feature (restriction of rights) is called RBAC, and it cannot be used together with SeLinux - either - or.
   In total, there are options, for example, the following:
   
   • PaX + GrSecurity
   • PaX + GrSecurity (without RBAC) + SeLinux
   • PaX + SeLinux
   • PaX + RSBAC
   • ... etc ...
   
   I chose the first (PaX + GrSecurity) because first, setting up SeLinux promises to be a nightmare, unlike GrSecurity / RBAC; secondly, in my opinion, the support of RSBAC in Gentoo is still damp; and thirdly, I liked GrSecurity, I liked it. :))

')
To be continued ...

Note: Some of the text was written over two years ago , and was published in the maillist gentoo-user-ru. I want to break the text into 4 parts (because on Habré, long topics are not welcome), plus supplementing it with information on the current state of affairs (but fundamentally nothing has changed since then, there are fewer minor problems).