Checksec output re: CONFIG_DEBUG_* entries

Discuss and suggest new grsecurity features

Moderators: spender, PaX Team

Checksec output re: CONFIG_DEBUG_* entries

Postby Neokernsec » Sat Mar 07, 2015 6:07 am

In the context of x86_64/3.14.34:

I realise checksec is an externally developed and maintained third-party "measurement" tool, but out of an interest to get an official statement from grsec developers, are the following kernel configuration entries still pertinent?

CONFIG_DEBUG_STRICT_USER_COPY_CHECKS
CONFIG_DEBUG_RODATA

Checksec flags these being disabled as a "defect", and this seems very misleading.

Likewise, there's a persistent mention of KERNHEAP, but that's obsolete or moribund as well?

In the vanilla kernel 3.14.34, I don't see any configuration items that enable those symbols, despite seeing occasional references to them in various kernel sources.

I ask because of threads like this one: viewtopic.php?f=3&t=1630&p=6465&hilit=CONFIG_DEBUG_RODATA

This thread makes the statement that KERNEXEC is a superset (and more security optimal setting) than RODATA. Is this still the case for x86_64 on modern kernels?
Neokernsec
 
Posts: 16
Joined: Sun Dec 30, 2012 8:53 am

Re: Checksec output re: CONFIG_DEBUG_* entries

Postby PaX Team » Sun Mar 08, 2015 7:06 pm

1. DEBUG_STRICT_USER_COPY_CHECKS doesn't quite work since gcc 4.6 or so where some change resulted in a lot less precision/coverage for the underlying builtin used by this config option. in any case, this is compile time checking only and you're much better off with USERCOPY.
2. KERNEXEC works fine on amd64 (and arm) too, though its performance impact is worse than on i386, so if all you want is read-only memory enforcement then DEBUG_RODATA can still be an option to consider.
3. KERNHEAP still exists but it hasn't been open source for quite some time now and i know of no alternatives.
PaX Team
 
Posts: 2310
Joined: Mon Mar 18, 2002 4:35 pm

Re: Checksec output re: CONFIG_DEBUG_* entries

Postby Neokernsec » Mon Apr 27, 2015 12:02 am

PaX Team wrote:2. KERNEXEC works fine on amd64 (and arm) too, though its performance impact is worse than on i386, so if all you want is read-only memory enforcement then DEBUG_RODATA can still be an option to consider.
I don't see an explicit option for DEBUG_RODATA, unless it's not available for x86_64?
3. KERNHEAP still exists but it hasn't been open source for quite some time now and i know of no alternatives.
Oh? What's the "product" called now? The URL the checksec tool used to provide has rotted away. For something so intriguing, I've not been able to find what it's become, open or closed source.
Neokernsec
 
Posts: 16
Joined: Sun Dec 30, 2012 8:53 am

Re: Checksec output re: CONFIG_DEBUG_* entries

Postby PaX Team » Mon Apr 27, 2015 5:02 am

DEBUG_RODATA is explicitly disabled under PaX, you'll have to remove the dependency on BROKEN from arch/x86/Kconfig.debug before you can enable it (and i'm not sure it'll actually work, it's not exactly a config option i care about much myself because of KERNEXEC). as for KERNHEAP, you'll have to contact the subreption guys, it's their product line.
PaX Team
 
Posts: 2310
Joined: Mon Mar 18, 2002 4:35 pm


Return to grsecurity development

cron