Re: exec-shield (maybe ITP kernel-patch-exec-shield)
Hi!
> > Right, it is not useful to have a memory protection patch that does not protect
> > certain important programs. It doesn't seem to be very difficult to fix though.
>
> Hmm? Well, it wouldn't be the default while such problems are not fixed,
> that's for sure. And kludging fixes is not an acceptable solutions in the
> minds of many (me included), so we wouldn't just "disable it for X" if there
> is any hope of a better solution.
Right! Exactly! Problems should be fixed, not the symptoms. This is exactly
why I have constantly been saying that exec-shield and the GCC 3.4 hacks for
exec-shield are not really good from a security point of view.
Tools should be used to either fix security problems or to make them managable.
Exec-shield and the GCC 3.4 hacks do not do either well.
Exec-shield happily switches on executable stack if an application asks for it.
LinuxThreads asks for non-executable stack. Therefore MySQL would run with
executable stack. PaX simply ignores these requests. And still MySQL works
fine on PaX. Therefore there is clearly no need to always honour these
requests. Where it is needed, the decision should be part of a security
policy and not be left to some compiler or other such tool.
> This does not slow the entering of PaX in Debian at all. It _does_ slow
> enabling it by default.
Fortunately, X is one of the exceptions. But a proper solution is being looked
at in fact.
Groetjes,
Peter Busser
--
The Adamantix Project
Taking high-security Linux out of the labs, and into the real world
http://www.adamantix.org/
Reply to: