grsecurity in kernel?

Gennady Kupava gb at bsdmn.com
Wed Dec 29 22:39:07 CET 2010


В Срд, 29/12/2010 в 23:28 +0100, Glenn пишет:
> At 0:06 +0200 30/12/10, Timo Juhani Lindfors wrote:
> >Glenn <glenn.mh.dk at gmail.com> writes:
> >>  Maybe it might be a good idea to embed grsecurity in the kernel - for
> >>  two reasons:
> >
> >I think the main goal should be to upstream our changes, not add new
> >changes that are not upstream.
> >
> >>  * Debug programs and drivers (faster debugging?)
> >
> >What has grsecurity to do with debugging?
> ...
> 
> 
> On there home page they write:
> 
> # Prevention of arbitrary code execution, regardless of the technique 
> used (stack smashing, heap corruption, etc)
> # Prevention of arbitrary code execution in the kernel
> # Randomization of the stack, library, and heap bases
> # Kernel stack base randomization
> # Protection against exploitable null-pointer dereference bugs in the kernel
> 
> E.g. Some buffer overflows will be stopped.

How do you see 'stopped buffer overflow'? Will it not overflow? I think
it will still overflow, but no harm to security. Of course at cost of
additional checks :)

In general:

This is just small phone, not super- secure device with highly secure
data serving public available services. All this will have negative
impact on performance and battery life.

You welcome to research how it will work - just build kernel, run
lmbench and see how much slower things will be, and use it if you like
to build super-secure device, if would be interesting to read summary of
your reserch, but

FR stacks has thousands of software bugs, better fix em in normal way,
not workaround by adding another chuck of self-checking.

Gennady.




More information about the community mailing list