[...]
> Let's look at your argument:
>
> Given: we have a process with an exploitable buffer overflow.
And a fix for said bug. What is better: Paper over the bug, creating a DoS
in the process, or fix the bug?
> Case A, stack is executable: your process stays up despite buffer overflows,
> and crackers silently get root on your machine.
> Case B, stack is non-executable: your process dies. Crackers don't get root.
> Your log screams at you that your process has security problems.
Case C, stack nonexecutable deosn't matter: Process is cracked. Continue as
(A), just sysadmin feeles secure
> And you are saying you prefer Case A? Wow..
C isn't any better than A...
> In an ideal world people would write good code, and we could allow the stack
> to be executable. But it's not an ideal world, and admin's don't have the
> time to audit every daemon they run.
In the real world, daemons get written carefully and are audited. If they
aren't, there are plenty of other attacks available (stack smashing is just
_one_ way to take advantage of a poorly written program).
> IMO non-exe stack should be a compile option, so that those who need/like
> paranoid setups can have that small extra bit of security. Granted, most
> people don't need it, and most people shouldn't use it. And support for
> various trampoline formats should be kept to a minimum. But it should be an
> option.
Get the patch and apply it. I prefer not to rely on papering over the
holes.
-- Horst von Brand vonbrand@sleipnir.valparaiso.cl Casilla 9G, Viņa del Mar, Chile +56 32 672616- 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/