Messages in this thread | | | Date | Mon, 14 Apr 1997 08:32:34 -0400 | From | "Theodore Y. Ts'o" <> | Subject | non-executable stack |
| |
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
| |