From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,e6ea6a59056d4060 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-03-28 12:34:55 PST Path: archiver1.google.com!news1.google.com!sn-xit-02!sn-xit-03!supernews.com!freenix!fr.clara.net!heighliner.fr.clara.net!newsfeed.hanau.net!news-fra1.dfn.de!news-koe1.dfn.de!news.rhrz.uni-bonn.de!news.uni-stuttgart.de!cert.uni-stuttgart.de!news.enyo.de!not-for-mail From: Florian Weimer Newsgroups: comp.lang.ada Subject: Re: GNAT 3.14p and Red Hat 7.2 Date: Thu, 28 Mar 2002 21:34:53 +0100 Organization: Enyo -- not your organization Message-ID: <87sn6kjus2.fsf@deneb.enyo.de> References: <3C9F40A2.5AF3920D@raytheon.com> <87g02nm7gm.fsf@deneb.enyo.de> <87sn6m4438.fsf@deneb.enyo.de> NNTP-Posting-Host: deneb.enyo.de Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: cygnus.enyo.de 1017347649 21963 212.9.189.171 (28 Mar 2002 20:34:09 GMT) X-Complaints-To: abuse@enyo.de NNTP-Posting-Date: 28 Mar 2002 20:34:09 GMT Cancel-Lock: sha1:okByr8ZxO1ajYXZWzsOTD8qqqOE= Xref: archiver1.google.com comp.lang.ada:21787 Date: 2002-03-28T20:34:09+00:00 List-Id: Georg Bauhaus writes: > I recall a discussion of OS security in the Minix book > by Tanenbaum, where he points out that you should not believe > in security because your system manual tells you some part > of the system has been secured. On the contrary, the mechanism > should be open to cracking attempts, to be tested. Did Tanenbaum really write that? What strange way to think about security! We haven't got just manuals, we have also got source code. Looking at the source code is far more efficient than random black box testing without vendor support. I'm surprised how many vulnerabilities are uncovered by more or less systematic black box testing, but such testing can only show the presence of bugs, not their absence. > Improved security due to the removal of one possible hole? Yes, of course, and it's not a "possible hole", it's a typical /tmp race condition. > Let me argue in favour of documenting possible holes. This particular problem has been documented over and over again. In fact, it is one of the most well-known security problems in UNIX-centered code. > If program writers learn to pay attention to the outcome > of the compilation process, and they must, once they now > even an Ada program doesn't just use RM virtuality, > they will care about what OS facilities operate behind the > scenes. Well, I *do* care, that's why I complain about the problem! But your advice not to fix such problems and just document them is entirely incomprehensible to me.