Horst von Brand writes: > Where do you think script kiddies get their exploit scripts from? They > don't write them themselves: The real crackers share them with the > community. Just like the hacker community shares patches and cool > programs. So you can keep out 99.99% only until one of the 0.01% finds out > a way around it. The danger of "nonexecutable stack" is that it creates a > sense of security, which might be justified as long as it is rare. Once it > becomes widespread, it will be useless in short time, and _everybody_ will > have to pay the cost for nothing at all, while feeling smugly secure.

Anyone who thinks that a non-executable stack can replace othersecurity measures is a fool. But arguing that a non-executablestack is not real protection because the widespread use ofsystems with non-executable stacks will only cause crackers toconcentrate on other holes is also foolish. You may as wellargue that file permissions are unnecessary becase well-behavedprograms and users won't mess with files they're not supposed to,and the existence of restrictive file permissions merely causescrackers to find ways around them.

In reality, many programs still exist with exploitable bufferoverflows and people are writing more. Code auditing and bettersoftware technology are not going to fix all of these programs.Just as you protect your files to prevent unwanted reading andwriting, I want global protection against unwanted code executionthat doesn't depend only on the competence of every coder.

I agree that any non-executable stack support should be anoption. If you don't want it, you don't have to have it. Iwould love to have it for any Linux server system I set up.

Ultimately, saying that we shouldn't have protection against anexisting security problem that shows no signs of going awaybecause other kinds of security problems will occur in the futureis a ridiculous argument.

-To unsubscribe from this list: send the line "unsubscribe linux-kernel" inthe body of a message to majordomo@vger.rutgers.eduPlease read the FAQ at http://www.tux.org/lkml/