On Tue, 4 Jul 2000 lamont@icopyright.com wrote:
>
> The problem is that non-executable stacks on x86 boxes can be gotten
> around in all cases where there already is an exploit. If you included
> Solar Designer's non-exec stack into the linux kernel and made it the
> default that'd just mean that non-exec stack exploits would become the
> norm. The result would be no net increase in security.
If the location of buffers isn't fixed, then it makes the problem very
difficult. I realize for all practical purposes, with a given compiler and
loader they are essentially fixed.
After looking at safelib a bit though, I agree with others that it's the
best prevention if it can be made portable.
> Stackguard is useful because it does block a class of exploits completely.
> If all you can do is overrun a single buffer and the only interesting
> thing you can do from there is modify the RA on the stack then StackGuard
> really will protect you. Of course if you can tweak a variable on the
> current stack frame and never touch the RA, then StackGuard buys you
> nothing. Libsafe is similarly useful.
Stackguard is presently limited to x86 and presently implimented only for
an old version of gcc; so it's only a partial solution for the x86 platform
only if you're willing to use antique tools.
But beyond that, I don't like to rely on one layer of security; it is
desirable to have multiple layers. What makes stackguard and non-executable
user stack area mutually exclusive? What makes either of those things and
safelib mutually exclusive?
And as I previously mentioned, a lot of other functionality in the patch
has value; even if it breaks POSIX rules (and I'm sorry if I'm speaking
blasphemly in front of those who bow down and worship the POSIX god's).
It's a configuration option. But I also understand Linus reluctance to have
a lot of ifdef's in the code; it makes it impossible to figure out what code
was actually compiled in and executed when something goes wrong.
As I stated early on though, this is a more minor issue; the patch is
well maintained and documented, easily to apply, so it's no big deal with each
new release. The low latency patch is another matter. But I fully realize
that it has no chance of being included.
I don't know how to go about making the measurements people want to
justify whether a schedualing point is needed. As I stated previously, I'd be
happy to do so if it's something I can physically do but I don't have hardware
sitting idle here that I can take down and do kernel profiling, etc.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Jul 07 2000 - 21:00:16 EST