The term "toolchain" refers to the combination of software packages commonly used to build and develop for a particular architecture. The toolchain you may hear referred to in the gentoo-hardened IRC channel consists of the GNU Compiler Collection (GCC), binutils, and the GNU C library (glibc).

The answer to this question is highly subjective, and very dependent on your requisites so the hardened Gentoo project simply tries to lay out each technology and leave the choice up to the user. This decision requires a lot of research that we have hopefully provided clearly in the hardened documentation. However, if you have any specific questions about the security model that each provides, feel free to question the relevant developer in our IRC channel or on the mailing list.

Yes, this combination is quite possible as PaX and some of Grsecurity's features work with Grsecurity's RBAC and SELinux. The only conflict that arises is you can only use one access control system (be it RBAC or SELinux).

No, the current toolchain implements the equivalent of CFLAGS="-fPIE -fstack-protector-all -D_FORTIFY_SOURCE=2" LDFLAGS="-Wl,-z,now -Wl,-z,relro" automatically through GCC's built-in spec and using the specfiles to disable them which is a more proper solution. For older hardened-gcc users the best approach is switch to the hardened profile and then upgrade following the steps on the How to switch to Gentoo Hardened question

You can use gcc-config to accomplish this:

# gcc-config -l
 [1] x86_64-pc-linux-gnu-4.4.4 *
 [2] x86_64-pc-linux-gnu-4.4.4-hardenednopie
 [3] x86_64-pc-linux-gnu-4.4.4-hardenednopiessp
 [4] x86_64-pc-linux-gnu-4.4.4-hardenednossp
 [5] x86_64-pc-linux-gnu-4.4.4-vanilla
 
To turn off PIE building switch to the hardenednopie profile:
# gcc-config x86_64-pc-linux-gnu-4.4.4-hardenednopie
To turn off SSP building switch to the hardenednossp profile:
# gcc-config x86_64-pc-linux-gnu-4.4.4-hardenednossp
To turn off SSP and PIE building switch to the hardenednopiessp profile:
# gcc-config x86_64-pc-linux-gnu-4.4.4-hardenednopiessp
To turn off all hardened building switch to the vanilla profile:
# gcc-config x86_64-pc-linux-gnu-4.4.4-vanilla
You need to run this on the active sessions to set the changes
# source /etc/profile

Alternatively you can achieve the same by changing your CFLAGS:

To turn off default SSP building when using the hardened toolchain, append -fno-stack-protector to your CFLAGS.

If you want to turn off default PIE building then append -nopie to your CFLAGS and your LDFLAGS (as LDFLAGS is used with no CFLAGS when using gcc to link thre object files).

If you want to turn off default now binding append -z,lazy to your LDFLAGS.

If you want to turn off default relro binding append -z,norelro to your LDFLAGS.

No, the Hardened Gentoo Project is a collection of subprojects that all have common security minded goals. While many of these projects can be installed alongside one another, some conflict as well such as several of the ACL implementations that Hardened Gentoo offers.

Using the gcc optimization flag -O3 has been known to be problematic with stack-smashing protector (SSP) and on vanilla builds in some situations. This optimization flag is not officially supported and is, therefore, discouraged by the hardened team. Compile issues where a user uses CFLAGS="-O3" may be closed as INVALID/CANTFIX and/or ignored.

To change your profile use eselect to choose it.

# eselect profile list
[1]   default/linux/amd64/10.0
[2]   default/linux/amd64/10.0/desktop
[3]   default/linux/amd64/10.0/desktop/gnome *
[4]   default/linux/amd64/10.0/desktop/kde
[5]   default/linux/amd64/10.0/developer
[6]   default/linux/amd64/10.0/no-multilib
[7]   default/linux/amd64/10.0/server
[8]   hardened/linux/amd64
[9]   hardened/linux/amd64/no-multilib
[10]  selinux/2007.0/amd64
[11]  selinux/2007.0/amd64/hardened
[12]  selinux/v2refpolicy/amd64
[13]  selinux/v2refpolicy/amd64/desktop
[14]  selinux/v2refpolicy/amd64/developer
[15]  selinux/v2refpolicy/amd64/hardened
[16]  selinux/v2refpolicy/amd64/server
# eselect profile set 8 (replace 8 with the desired hardened profile)

After setting up your profile, you should recompile your system using a hardened toolchain so that you have a consistent base:

# emerge --oneshot binutils gcc virtual/libc
Make sure the hardened toolchain is being used (gcc version may vary):
# gcc-config -l
 [1] x86_64-pc-linux-gnu-4.4.4 *
 [2] x86_64-pc-linux-gnu-4.4.4-hardenednopie
 [3] x86_64-pc-linux-gnu-4.4.4-hardenednopiessp
 [4] x86_64-pc-linux-gnu-4.4.4-hardenednossp
 [5] x86_64-pc-linux-gnu-4.4.4-vanilla
If the hardened version isn't chosen select it
# gcc-config x86_64-pc-linux-gnu-4.4.4
# source /etc/profile
Keep emerging the system
# emerge -e --keep-going system
# emerge -e --keep-going world

The --keep-going option is added to ensure emerge won't stop in case any package fails to build.

We have written a document on how to debug with Gentoo Hardened, so following the recommendations there should fix your problem.

JIT means Just In Time Compilation and consist on taking some code meant to be interpreted (like Java bytecode or JavaScript code) compile it into native binary code in memory and then executing the compiled code. This means that the program need a section of memory which has write and execution permissions to write and then execute the code which is denied by PaX, unless the mprotect flag is unset for the executable. As a result, we disabled the JIT use flag by default to avoid complaints and security problems.

You should bear in mind that having a section which is written and then executed can be a serious security problem as the attacker needs to be able to exploit a bug between the write and execute stages to write in that section in order to execute any code it wants to.

If you need it, we recommend enabling the flag in a per package basis using /etc/portage/package.use

x11-libs/qt-core jit
x11-libs/qt-script jit
x11-libs/qt-webkit jit

Anyway, you can enable the use flag globally using /etc/make.conf

CFLAGS="-O2 -pipe -fomit-frame-pointer -march=native"
CXXFLAGS="${CFLAGS}"
# WARNING: Changing your CHOST is not something that should be done lightly.
# Please consult http://www.gentoo.org/doc/en/change-chost.xml before changing.
CHOST="x86_64-pc-linux-gnu"
# These are the USE flags that were used in addition to what is provided by the
# profile used for building.
#If you have more uses adding jit to the end should suffice
USE="jit"

MAKEOPTS="-j2"

GENTOO_MIRRORS="ftp://ftp.udc.es/gentoo/"

SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage"

That is the homepage for PaX.

Currently the only Gentoo documentation that exists about PaX is a PaX quickstart guide.

PaX markings are a way to tell PaX which features should enable (or disable) for a certain binary.

Features can either be enabled, disabled or not set. Enabling or disabling them will supersede the kernel action, so a binary with a feature enabled will always use the feature and one with a feature disabled won't ever used it.

When the feature status is not set the kernel will choose whether to enable or disable it. By default, the hardened kernel will enable those features with only two exceptions, the feature is not supported by the architecture/kernel or PaX is running in Soft Mode. In those two cases, it will be disabled.

Text relocations are a way in which references in the executable code to addresses not known at link time are solved. Basically they just write the appropriate address at runtime marking the code segment writable in order to change the address then unmarking it. This can be a problem as an attacker could try to exploit a bug when the text relocation happens in order to be able to write arbitrary code in the text segment which would be executed. As this also means that code will be loaded on fixed addresses (not be position independent) this can also be exploited to pass over the randomization features provided by PaX.

As this can be triggered for example by adding a library with text relocations to the ones loaded by the executable, PaX offers the option CONFIG_PAX_NOELFRELOCS in order to avoid them. This option is enabled like this:

-> Security options
  -> PaX
    -> Enable various PaX features
      -> Non-executable pages
        [*] Restrict mprotect()
        [*]   Allow ELF text relocations

If you are using the gentoo hardened toolchain, typically compiling your programs will create PIC ELF libraries that do not contain text relocations. However, certain libraries still contain text relocations for various reasons (often ones that contain assembly that is handled incorrectly). This can be a security vulnerability as an attacker can use non-PIC libraries to execute his shellcode. Non-PIC libraries are also bad for memory consumption as they defeat the code sharing purpose of shared libraries.

To disable this error and allow your program to run, you must sacrifice security and allow runtime code generation for that program. The PaX feature that allows you to do that is called MPROTECT. You must disable MPROTECT on whatever executable is using the non-PIC library.

To check your system for textrels, you can use the program scanelf from app-misc/pax-utils. For information on how to use the pax-utils package please consult the Gentoo PaX Utilities Guide.

As part of its design, the Java virtual machine creates a considerable amount of code at runtime which does not make PaX happy. Although, with current versions of portage and java, portage will mark the binaries automatically, you still need to enable PaX marking so PaX can do an exception with them and have paxctl installed so the markings can be applied to the binaries (an reemerge them so they are applied).

This of course can't be applied to all packages linking with libraries with JIT code, so if it doesn't, there are two ways to correct this problem:

-> Security options
  -> PaX
    -> Enable various PaX features
      -> PaX Control
        [*] Use ELF program header marking

# emerge paxctl

When you already have paxctl emerged you can do:

# paxctl -pemrxs /path/to/binary

This option will slightly modify the ELF header in order to correctly set the PAX flags on the binaries.

The other way is using your security implementation to do this using the kernel hooks.

Although this is not advised except when used to rescue the system or for debugging purposes, it is possible to change a few of PaX behaviours on boot via the kernel command line.

Passing pax_nouderef in the kernel cmdline will disable uderef which can cause problems on certain virtualization environments and cause some bugs (at times) at the expense leaving the kernel unprotected against unwanted userspace dereferences.

Passing pax_softmode=1 in the kernel cmdline will enable the softmode which can be useful when booting a not prepared system with a PaX kernel. In soft mode PaX will disable most features by default unless told otherwise via the markings. In a similar way, pax_softmode=0 will disable the softmode if it was enabled in the config.

That is the homepage for Grsecurity.

The most current documentation for Grsecurity is a Grsecurity2 quickstart guide.

We have written a document with some information on how TPE works in the different settings.

Usually we release a new version of hardened sources not long after a new PaX/Grsecurity patch is released, so the best option is just waiting a bit for the kernel team to adapt the patches and then test them. Remind that we won't support kernel sources not coming from the portage tree.

There is a SELinux specific FAQ .