5

I was wondering if the hardened profile from Gentoo was really more secure than any other distro (like Debian, RHEL, Arch ...). For those who don't know, Gentoo hardened allows a system to be built system-wide with specific hardening GCC options (pie, ssp, relro, ...) and other few things (grsec/selinux ...).

For example, I know Arch Linux does not build all binaries with those GCC hardening flags, so does it imply some sort of concern about security?

I know OpenVPN is built without PIE and partial relro. Does this mean that if an exploit is found against OpenVPN, an Arch installation may be less secure than a Gentoo one?

TL;DR: is it a real advantage using Gentoo Hardened over any other distro in terms of security of binaries?

4

Its all in the source! Gentoo hardened is an security driven distro the hardened profile really packs a great deal into making it really secure.

But is it worth the compile? 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 don'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 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 writeable 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? lets 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 randomized, 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 .ctors, .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 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 armor)
  • 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 rsbac-sources kernel to build a kernel with rsbac support.

It all comes down to the big question as stated earlier? Worth the Compile? Really comes down to how or what you are securing and is the effort worth while? Or will you be able to truly secure what you do not want prying eyes to see?

  • 1
    Okay, thank you for the clarification of all these security enforcement technologies. So if I understand your point, these items are very useful to improve security of a system; but you ask "is it worth it the compile?". So, why are they not enabled by default in some major distros ? I read that PaX on a desktop may break some binaries (heard of java or firefox) ; is it the only reason ? – Lqp1 Mar 17 '16 at 19:09
  • 1
    The reason PaX and grsecurity are not the default on many distros is due to politics and egos. The developers of both of those have personalities that clash strongly with the Linux kernel dev team. In addition to that, they do not wish to take the time to break up their patch into chunks that would be accepted into upstream, and instead use their time to develop more security features. – forest Apr 4 '16 at 4:09
  • 2
    Also note that grsecurity is not an access control system. Spender (creator of grsecurity) gets very irritated when people call it an access control system and then compare it to SELinux. :P Grsecurity is a combination of kernel patches that increases kernel security by eliminating bug classes. The RBAC access control system it has is inconsequential compared to the rest. Grsecurity's security features are so extensive that it would take up far more room than could be put in a single post. Check out grsecurity.net to see a pretty comprehensive list. – forest Apr 4 '16 at 4:13
  • while it adds some security it's so little that it's not worth it in most cases – Uh, this is totally incorrect. And the security really has nothing at all to do with hiding addresses. I'm amazed that this answer is upvoted. – forest Sep 14 at 3:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.