> 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/