Hardened Gentoo: Installation

The installation of Hardened Gentoo (more precisely, the upgrade of the current Gentoo system in Hardened) looks like this:

1. switch to hardened toolchain and rebuild the whole system with it so that all binaries use PIE and SSP (after that the system becomes protected by SSP)
2. install hardened-sources (they contain PaX + GrSecurity + SeLinux + additional patches from Gentoo) and compile them with support for PaX, GrSecurity and GrSecurity / RBAC
3. we are overloaded with the new kernel (after that, the system is also protected by PaX + PIE and GrSecurity)
4. for some time we set up and debug access restrictions (after which the system is also protected by GrSecurity / RBAC)

Expected problems:

• not everything can be compiled with PIE + SSP - perhaps separate packages will need to be patched or compiled without one or both of them (I still needed to switch to vanilla gcc via gcc-config only to compile the X's so that they work with ATI firewood)
• not everything can work normally, because some programs (usually mentioning X's and java) use the execution of dynamically generated code for completely legal purposes, and now when they try to do this they will be stitched with either SSP or PIE + PaX - for these programs you will need to individually disable some of the PaX protections (for this there are special utilities, for example paxctl) and / or compile them without SSP
• not everything can work due to the limitations of the “features” of the GrSecurity core - in this case, you will need to disable some of the GrSecurity protection (globally, in make menuconfig)
• setting access restrictions may not be easy, and at any time when a thread of the prog does something that we did not take into account when setting up its rights - it will be nailed by the kernel ... and these rules will have to be fixed as a matter of urgency

Here we go… :)

Too strong optimization (-O3) together with hardened toolchain can lead to different glitches and compilation failures, so you need to replace -O3 with -O2 in /etc/make.conf and remove all other -f * optimizer flags.

Go to hardened profile. (Theoretically, instead, one could simply add to the USE flags: “hardened pie ssp”.)

ln -snf ../usr/portage/profiles/hardened/x86/2.6/ /etc/make.profile 

After switching the profile to hardened / x86 / 2.6 /, several USE flags I needed turned off, which are automatically enabled in regular profiles - I added them to make.conf (you may have other flags, just remember to track this point):

 avi encode gtk2 jpeg mpeg oss quicktime spell truetype xv bitmap-fonts truetype-fonts type1-fonts 

Compiling hardened-toolchain and rebuilding it for all other packages:

 emerge binutils gcc glibc emerge -e world dispatch-conf 

Next, you need to put some more packages:

 emerge paxtest paxctl gradm 

paxtest could have been put before, before switching to hardened toolchain. This utility tries to do various dangerous operations (such as stack overflow with code execution), which are usually performed by exploits. If the system is protected, then all its attempts will be stopped, as it will inform. In general, you can drive it before installing the hardened toolchain, after as well after rebooting with the kernel where PaX is enabled, for fun. :)
')
paxtest as its dependency will also install the prog chpax - this is the old way to manage PaX, instead of which it is better to use paxctl. But some programs distributed without source code are compiled so that paxctl cannot work with them, and you have to use chpax.

Well, gradm is needed to configure RBAC in GrSecurity - the very same rights restrictions for processes and users.

As for the kernel settings. To begin with, I configured everything as described in the Gentoo and GrSecurity dock - not all protections are included, but most software will work with such settings. In the process of analyzing the settings, several theoretical assumptions arose:

• If you load the hardened kernel BEFORE recompiling the system, problems may arise if this option is enabled:
  

   PaX -> Non-executable pages -> Disallow ELF text relocations 

• On a server where there are no Xs, you can additionally enable: (do not forget to check before this that something other than Xes, in particular, hwclock, has not stopped working):
  

   Grsecurity -> Address Space Protection -> Disable privileged I/O 

• In addition, there is also an assumption that some chroot restrictions may interfere with operations such as installing Gentoo (which goes inside chroot) or attempting to repair the system (if, for example, to boot from a CD with such a hardened kernel):
  

   Grsecurity -> Filesystem Protections -> Deny mounts Grsecurity -> Filesystem Protections -> Deny double-chroots Grsecurity -> Filesystem Protections -> Deny (f)chmod +s Grsecurity -> Filesystem Protections -> Deny mknod 

Start. To be continued ...