grsecurity forums

Hi!

I installed the grsec patch on my machine with Debian Woody 2.4.18 kernel and I compiled the kernel with some of the randomized features.
But I can't find the directory /proc/sys/kernel/grsecurity
How can I enable rand_ipids and rand_ttl?

Were you using 1.9.9c?

/proc/sys/kernel/grsecurity only exists if grsecurity is enabled in the kernel. There will only be an entry for "acl" unless you specify the sysctl option of grsecurity, in which case the directory will be populated with entries for most other features of grsec. If you haven't enabled the sysctl option, everything you enabled in the kernel config works automatically as you configured it.

-Brad

I am using 1.9.4, it's the patch provided by Debian.

I have another question:
I am using glibc 2.2.5 and I have enabled the Openwall non-executable stack. When I read the documentation you said that I must enable also Gcc trampoline support if using glibc 2.0. Do I have to enable this although I am using 2.2.5?


Thanks,
Gerald

Flanders wrote:I am using glibc 2.2.5 and I have enabled the Openwall non-executable stack. When I read the documentation you said that I must enable also Gcc trampoline support if using glibc 2.0. Do I have to enable this although I am using 2.2.5?

gcc trampolines are independent of glibc versions, you need that emulation if you have applications that use that feature (you'll find them out soon enough because they will crash without emulation).

(you'll find them out soon enough because they will crash without emulation).

Why not just run emulation regardless? I'm assuming that the emulation mode is relatively secure. Is their overhead involved with it enabled?

Using the emulation on everything could open up a hole such that the attacker could create some code that acts as one of the trampolines to be emulated, and use it to profit his exploit. This problem is explained in the documentation for the emulation feature in the kernel configuration.

-Brad

ethan@plaxo.com wrote:Why not just run emulation regardless? I'm assuming that the emulation mode is relatively secure. Is their overhead involved with it enabled?

there is indeed an overhead because emulation requires a user/kernel transition which on i386 is quite expensive (several hundreds of cycles). but that's not the reason for its not being automatic. as Brad already said, emulation (be that gcc trampolines or something else) implies that an attacker can make use of it as well. depending on how much 'state' the code in question changes, it may or may not help the attack. the gcc trampolines allow one to load a register with arbitrary value and jump to an arbitrary location. while the latter gains nothing for an attack, the former does (or may at least) and hence i decided to be on the safe side and not allow automatic emulation.

i made only one exception in the past: EMUSIGRT which allows one to use a libc that doesn't supply its own signal restorer (like uClibc back then), and i don't plan to make more. nevertheless, the change to do automatic gcc trampoline emulation is very simple, one just has to ignore the EMUTRAMP flag in pax_handle_fetch_fault(), everyone who really wants it can just remove that check (or alternatively use the ACL system and the G subject flag).

Thanks guys, for the clarification. Your ability to answer (silly?) questions is a great service to the projects you support.