Security Level: high/server/workstation/virtualization
Hi!
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 real use. 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_IO + CONFIG_GRKERNSEC_KERN_LOCKOUT + CONFIG_GRKERNSEC_PROC_ADD + + CONFIG_GRKERNSEC_SYSFS_RESTRICT + CONFIG_GRKERNSEC_PROC_IPADDR + + + CONFIG_GRKERNSEC_RWXMAP_LOG + + + CONFIG_GRKERNSEC_SYSCTL + + + CONFIG_GRKERNSEC_SYSCTL_ON + + + CONFIG_PAX_PER_CPU_PGD + + + - CONFIG_PAX_ELFRELOCS + 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: CONFIG_GRKERNSEC_ACL_HIDEKERN CONFIG_GRKERNSEC_EXECLOG CONFIG_GRKERNSEC_CHROOT_EXECLOG CONFIG_GRKERNSEC_AUDIT_PTRACE CONFIG_GRKERNSEC_AUDIT_CHDIR CONFIG_GRKERNSEC_AUDIT_TEXTREL CONFIG_GRKERNSEC_BLACKHOLE CONFIG_PAX_EMUTRAMP CONFIG_PAX_MPROTECT_COMPAT CONFIG_PAX_MEMORY_STACKLEAK 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. -- WBR, Alex. |
Security Level: high/server/workstation/virtualization
On Fri, 27 Jan 2012 15:26:26 +0200
Alex Efros wrote: Thanks for the info. In a discussion about malloc flags, it was mentioned on the OpenBSD list that clearing the memory immediately brought little in security as it would be cleared before re-use and if anything could increase the chances of an attacker writing to areas that he wanted to. > Core2Duo I don't know the details but according to OpenBSDs Theo, the Core2Duo had some major design flaws that intel couldn't fix with microcode with some security implications. |
| All times are GMT. The time now is 10:36 PM. |
VBulletin, Copyright ©2000 - 2013, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.