[lkml]   [1999]   [Dec]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 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

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.

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
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:55    [W:0.127 / U:0.436 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site