Messages in this thread | | | Date | Mon, 27 Dec 1999 18:28:22 -0500 (EST) | From | "Richard B. Johnson" <> | Subject | Re: Unexecutable stack |
| |
On Mon, 27 Dec 1999, Zachary Amsden wrote:
> Just for reference, here are the facts: > > 1) Not all architectures support this > 2) It breaks trampoline code > 3) It doesn't provide full protection > 4) It does raise the bar significantly, in that it stops script kiddies > 5) Most modern daemons are smart enough to switch to unprivileged UIDs when > parsing user input, and use strnxxx library functions. > > I would say that all considered, it is not worthwhile unless you need to run > a bunch of old setuid programs. In that case, you are taking a big risk even > with the patch. > > --
You are correct. The problem is that when one talks about 'security' the definition remains undefined. The most secure computer is one that is locked up and turned OFF. This is not a very useful tool. On the other hand, we have computers visible on the internet with no root password. You get security by obscurity here.
If you make all network daemons 'eat' everything you send them that is not correct, a hacker gets no feedback so this seems more secure than a daemon that disconnects when it thinks it's being attacked. In both cases, the hacker isn't going to 'get in' only waste a few CPU cycles. So, which is 'more' secure? It's all in perception. If it is impossible for code, unintended to be executed on the stack, to be executed, then why would you make the stack non-executable?
There is a case that can be made for the code-segment ".text" to be non-writable. It prevents a hardware glitch from modifying code. There is also a case that can be make for making this segment non-readable because it can become a covert communications channel. However, it is very unlikely that either would enhance the security of any system you are likely to encounter in a lifetime.
Cheers, Dick Johnson
Penguin : Linux version 2.3.13 on an i686 machine (400.59 BogoMips). Warning : The end of the world as we know it requires a new calendar. Seconds : 365498 (until Y2K)
- 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/
| |