It's all in the source! Gentoo hardened is a security driven distro the hardened profile really packs a great deal into making it really secure. But is it worth compiling? A big question among the linux forums. Lets look at Gentoo hardened profile in terms of security:
while it adds some security it's so little that it's not worth it in most cases. It provides more security on a binary distro because everyone has the same binaries and an attacker doesn't need to guess where a specific piece of code may get loaded but by running a source distro your address space is already pretty unique. The only case where it provides some security is when an attacker is trying to guess an address for an exploit, making the wrong guess will likely crash the process and it will be reloaded on a new address. Do you have valuable enough data for an attacker to go through that hassle in order to get it? If you do then you should use a hardened profile, but physical security and disk encryption is more important because if it's worth that much it'll be easier to just rob you.
Be aware that there's no hardened desktop profile so that alone will make it somewhat harder if you plan to use it on a desktop.
Another reason is if you want to use something like SELinux (which doesn't require a hardened profile) that gives you very fine grained control about access control but it's also very restrictive. I think it's only worth it for large networks with many users and different levels of access to sensitive data. I needed some of SELinux features but settled for using AppArmor in an unusual way to accomplish them because SELinux is too much trouble. All AppArmor really does is provide process isolation or sandboxing. If an attacker gains access through an exploint he will only be able to access the files that the exploited service has access to. I use it with a catch all profile that prevents execution from all world writable and home directories, and access to ssh/pgp keys, keyrings, etc. This works nice for servers and desktops and is not too restrictive. And if I need to execute code from my home dir for development I can launch an unrestricted shell via sudo. I can leave my laptop unlocked with the wallet open (I use the kwallet pam module) and it will be really hard for you to get anything like ssh keys or passwords (I also have patches for kwallet so it requires a password to show saved passwords), but the programs that need them have access to them.
But what makes it hardened? Let's look at some of those items as well:
PaX is a kernel patch that protects us from stack and heap overflows. PaX does this by using ASLR (address space layout randomization), which uses random memory locations in memory. Each shellcode must use an address to jump to embedded in it in order to gain code execution and, because the address of the buffer in memory is randomised, this is much harder to achieve. PaX adds an additional layer of protection by keeping the data used by the program in a non-executable memory region, which means an attacker won’t be able to execute the code it managed to write into memory. In order to use PaX, we have to use a PaX-enabled kernel, such as hardened-sources.
PIE/PIC (position-independent code): Normally, an executable has a fixed base address where they are loaded. This is also the address that is added to the RVAs in order to calculate the address of the functions inside the executable. If the executable is compiled with PIE support, it can be loaded anywhere in memory, while it must be loaded at a fixed address if compiled with no PIE support. The PIE needs to be enabled if we want to use PaX to take advantage of ASLR.
RELRO (relocation read-only): When we run the executable, the loaded program needs to write into some sections that don’t need to be marked as writable after the application was started. Such sections are .actors, .dtors, .jcr, .dynamic, and .got [4]. If we mark those sections as read-only, an attacker won’t be able to use certain attacks that might be used when trying to gain code execution, such as overwriting entries in a GOT table.
SSP (stack-smashing protector) is used in user-mode; it protects against stack overflows by placing a canary on the stack. When an attacker wants to overflow the return EIP address on the stack, he must also overflow the randomly chosen canary. When that happens, the system can detect that the canary has been overwritten, in which case the application is terminated, thus not allowing an attacker to jump to an arbitrary location in memory and execute code from there.
RBAC (role-based access control): Note that RBAC is not the same as RSBAC, which we’ll present later on. The RBAC is an access control that can be used by SELinux, grsecurity, etc. By default, the creator of a file has total control over the file, while the RBAC forces the root user to have control of the file, regardless of who created it. Therefore all users on the system must follow the RBAC rules set by the administrator of the system.
Additionally, we can also use the following access control systems, which are used to control access between processes and objects. Normally, we have to choose one of the systems outlined below, because only one of the access control systems can be used at a time. Access control systems include the following:
- SELinux (security-enhanced Linux)
- AppArmor (application armour)
Grsecurity, which contains various patches that can be applied to the kernel to increase the security of a whole system. If we would like to enable grsecurity in the kernel, we must use a grsecurity-enabled kernel, which is hardened-sources. RSBAC (rule set-based access control): We must use the rsbac-sources kernel to build a kernel with rsbac support.
