[4284] in bugtraq
non-executable stack
daemon@ATHENA.MIT.EDU (Theodore Y. Ts'o)
Mon Apr 14 16:07:25 1997
Date: Mon, 14 Apr 1997 08:32:34 -0400
Reply-To: "Theodore Y. Ts'o" <tytso@MIT.EDU>
From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
X-To: "David S. Miller" <davem@jenolan.rutgers.edu>
To: BUGTRAQ@NETSPACE.ORG
In-Reply-To: David S. Miller's message of Mon, 14 Apr 1997 05:26:26 -0400,
<199704140926.FAA00615@jenolan.caipgeneral>
Date: Mon, 14 Apr 1997 05:26:26 -0400
From: "David S. Miller" <davem@jenolan.rutgers.edu>
Perhaps some people don't understand, every single Linux binary on
every platform supported that I know of, needs an executable stack to
have signals work at all. When you type 'ls' a signal can get
delivered to your shell to notify it that the child has exited. Just
about every program needs signals that is of any use.
David,
I had the exact same initial reaction, and then I took a closer
look at the kernel patch. It has a special-case kludge to temporarily
allow kernel stack code for signal handler return case.
There is still the problem of dealing with Objective C tramolines and
Gnu Libc 2.0 trampolines (which have already been removed for the next
release).
I agree with you that we can't ignore Objective C; but if we *can* find
solutions for all of the places where trampoline code is used, I think
denying stack executable access is a valuable. It does help "harden"
the OS, which is a Good Thing.
As far as breaking things go, if we can find all existing places that
use stack executable code and fix them, I think we're in the clear. No
standard ANSI C (or otherwise) specifies that executing code on the
stack *has* to work.
And while I'm sympathetic to calls that we shouldn't break things like
data segment executability for things like crashme, a possible
compromise would be to have a system call that enabled or disabled
things like data segment and stack segment executability. If you're
running a program (like httpd or sendmail) that has no call for such
features (i.e., doesn't use dlopen, doesn't use nested function calls,
etc.), why open yourself up to risk? The secuirty prinicple of "least
privilege" comes into play here.
- Ted
