> security. But we won't get _truly_ secure programs until people can > program securely; and people that can program securely can > write secure > programs in _any_ language. This sounds suspiciously like an argument that has been going on in the Linux-security mailing list. Basically the thrust of both arguments are: 1) We can't secure the world. 2) Therefore we won't secure part of the world. Sure we're going to have race conditions. Sure if you're klutzy enough it's possible to have arbitrary commands executed via system(). It's also possible to leverage root via a buffer overflow. Would you argue that we shouldn't bother fixing race conditions because there would still be buffer overflows out there to get us? It's basically the same argument turned on its tail. What I'm trying to get at, is that we, as a community, have to start somewhere, and a bounds checking compiler (of any stripe, including C) is a good place to start. There will always be poor programmers out there so long as we don't require authenticated IQ results with each software packages :). Therefore, promoting tools that put some guardrails in place seems prudent. If the guard rails are necessary in a portion of your program, then use the disable-bounds-checking compiler directive for that portion of your code by all means. But I'd personally feel better about OKing any suid code in an audit if it was bounds checked. Just my $.02 + GST. Dale Babiy
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:06:55 PDT