If you ever wonder how exactly differs predefined security levels, you'll
find this information here.
I've compared them, plus I did some
benchmarking (Core2Duo E6600, 32bit OS, hardened-sources-3.1.5,
single-user mode, kernel compile with -j3 as average user+sys time in 3 tests).
This information shouldn't surprise hardened developers, but if there are
some bugs with these levels then chances are you'll notice them now.
I didn't tested low and medium levels because I don't think they have any
First table: differences between these security levels.
"-" mean this level switch off that option
"+" mean this level switch on that option
" " mean this level doesn't change that option
high server ws virt
CONFIG_X86_32_LAZY_GS - -
CONFIG_CC_STACKPROTECTOR - -
CONFIG_GRKERNSEC_PROC_ADD + +
CONFIG_GRKERNSEC_PROC_IPADDR + + +
CONFIG_GRKERNSEC_RWXMAP_LOG + + +
CONFIG_GRKERNSEC_SYSCTL + + +
CONFIG_GRKERNSEC_SYSCTL_ON + + +
CONFIG_PAX_PER_CPU_PGD + + + -
CONFIG_PAX_KERNEXEC + + + -
CONFIG_PAX_KERNEXEC_MODULE_TEXT 4 4 4 -
CONFIG_PAX_MEMORY_SANITIZE + + +
CONFIG_PAX_MEMORY_UDEREF + + -
As you can see, if you switch between several levels you may end with
different options on same level - for example, switching from server to
workstation result in UDEREF on, while switching from virtualization to
workstation result in UDEREF off. That's correct, but you should keep this
in mind and re-check configuration after switching security level.
Next, list of options which doesn't changed by any of these security
levels, i.e. they are left completely up to user's choice. I'll show them
both in CONFIG and menuconfig formats:
Grsecurity ---> [*] Grsecurity
Role Based Access Control Options --->
[ ] Hide kernel processes
Kernel Auditing --->
[ ] Exec logging
[ ] Log execs within chroot
[ ] Ptrace logging
[ ] Chdir logging
[ ] ELF text relocations logging (READ HELP)
Network Protections --->
[ ] TCP/UDP blackhole and LAST_ACK DoS prevention
PaX ---> [*] Enable various PaX features
Non-executable pages --->
[ ] Emulate trampolines
[ ] Use legacy/compat protection demoting (read help)
Miscellaneous hardening features --->
[ ] Sanitize kernel stack
All other GrSecurity/PaX options are switched on by all these security levels.
Now, about benchmarking. I've enabled as much options as possible on
workstation: server security level PLUS all good optional options MINUS
CONFIG_GRKERNSEC_IO (for Xorg). And compared it to completely non-hardened
environment (kernel with GrSecurity/PaX switched off and vanilla gcc).
This way hardened was ~5% slower.
Without CONFIG_PAX_MEMORY_STACKLEAK it become ~3% slower.
Without CONFIG_PAX_MEMORY_STACKLEAK and CONFIG_PAX_MEMORY_SANITIZE - ~1% slower.
As for me, spending ~1% performance for ~all hardened is good trade off,
but spending 4% more for protection against leaking information in freed
memory is too much for workstation (and for most servers too), so I
recommend to change workstation security level to not enable
CONFIG_PAX_MEMORY_SANITIZE by default.