Re: thoughts on kernel security issues

From: Arjan van de Ven
Date: Thu Jan 13 2005 - 13:54:27 EST


On Thu, 2005-01-13 at 09:19 -0800, Linus Torvalds wrote:
>
> On Thu, 13 Jan 2005, Arjan van de Ven wrote:
> >
> > I think you are somewhat misguided on these: the randomisation done in
> > FC does NOT prohibit prelink for working, with the exception of special
> > PIE binaries. Does this destroy the randomisation? No: prelink *itself*
> > randomizes the addresses when creating it's prelink database
>
> There was a kernel-based randomization patch floating around at some
> point, though. I think it's part of PaX. That's the one I hated.
>
> Although I haven't seen it in a long time, so you may well be right that
> that one too is fine.

I don't know about the pax one, we were careful with the fc one to not
break prelink for obvious reasons ;)

> I just think that forking at some levels is _good_. I like the fact that
> different vendors have different objectives, and that there are things
> like Immunix and PaX etc around. Of course, the problem that sometimes
> results in is the very fact that because I encourage others to have
> special patches, they en dup not even trying to feed back _parts_ of them.

actually I was hoping to feed some bits of execshield (eg the
randomisation) to you sometime in the next weeks/months, after a
thorough cleaning of the code, and defaulting to off.

The code can be made quite reasonable I suspect if I manage to find a
few hours to clean it up some
(the pre-cleanup patch is at
http://www.kernel.org/pub/linux/kernel/people/arjan/execshield/00-
randomize-A0

in case you want to see for yourself)

that patch randomizes the stack (well already done via an x86 specific
hack in the existing kernel, this pulls that more generic)
the brk start
the start of mmap space (but leaves mmaps where the app gives a hint for
the address alone, like ld.so does for prelinked libs)




-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/