non-executable stack

[tytso () MIT EDU (Theodore Y. Ts'o)]

   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