FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Hardened

 
 
LinkBack Thread Tools
 
Old 01-27-2012, 12:26 PM
Alex Efros
 
Default 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.
 
Old 01-27-2012, 03:25 PM
Kevin Chadwick
 
Default 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.
 

Thread Tools




All times are GMT. The time now is 06:50 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org