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?
