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-29 08:02:06 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!newsfeeds.belnet.be!news.belnet.be!ossa.telenet-ops.be!nmaster.kpnqwest.net!blackbush.xlink.net!blackbush.de.kpnqwest.net!news-kar1.dfn.de!news-ham1.dfn.de!news.uni-hamburg.de!cs.tu-berlin.de!uni-duisburg.de!not-for-mail From: Georg Bauhaus Newsgroups: comp.lang.ada Subject: Re: GNAT 3.14p and Red Hat 7.2 Date: Fri, 29 Mar 2002 16:02:05 +0000 (UTC) Organization: GMUGHDU Message-ID: References: <3C9F40A2.5AF3920D@raytheon.com> <87g02nm7gm.fsf@deneb.enyo.de> <87sn6m4438.fsf@deneb.enyo.de> <87sn6kjus2.fsf@deneb.enyo.de> NNTP-Posting-Host: l1-hrz.uni-duisburg.de X-Trace: a1-hrz.uni-duisburg.de 1017417725 3453 134.91.4.34 (29 Mar 2002 16:02:05 GMT) X-Complaints-To: usenet@news.uni-duisburg.de NNTP-Posting-Date: Fri, 29 Mar 2002 16:02:05 +0000 (UTC) User-Agent: tin/1.5.8-20010221 ("Blue Water") (UNIX) (HP-UX/B.11.00 (9000/800)) Xref: archiver1.google.com comp.lang.ada:21843 Date: 2002-03-29T16:02:05+00:00 List-Id: Florian Weimer wrote: : 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! Maybe I should try to state this more clearly. Some quotes: `First, the system design should be public. Assuming that the intruders do not know how the system works serves only to delude the designers.' `Fifth, the protection mechanism should be ... built into the lowest layers of the system. Trying to retrofit security to an existing insecure system is nearly impossible.' : We haven't got just manuals, we have also got source code. yes, see above. : Looking at : the source code is far more efficient than random black box testing : without vendor support. Maybe, don't know the efficiency scale here, but why look at OS source code in order to be free to care less about null string file names, because the compiler is smart enough to work around OS's race conditions? I was trying to argue that while this may be "fixed", it might support the false idea that Ada programs are safe by RM and good OS aware compilers. That's a dangerous aproach in my view! : but such : testing can only show the presence of bugs, not their absence. Neither can the absence be shown to a degree that deserves the name security. There is none, only protection (OS), trust (human), and a good setup (both). :> 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. So it is a typical hole, that's not a compliment for ___ {, ___} (fill in here). (Important point. What is the intention of forcing mkstemp()? Beeing able to say, "See, no GNU Ada program introduces security problems by using race-condition OS facilities?") : 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. So change UNIX. Don't change the look of its system calls. See above, quote 2. : But your : advice not to fix such problems and just document them is entirely : incomprehensible to me. I think an OS problem should not be fixed by a compiler, introducing the possibility of a non-portable fix-me-once-more problem, should there be another operating system with shared scratch space, and someone wants to adapt the compiler to that system. (Again in an attempt to free programmers from having to think about possible security holes introduced by their programs?) And for programs that should run under high protection, as opposed to an operating system that should be protected from the vulnerabilities of its inherent race conditions (mkstemp() is a _workaround_, since the originals are still there), I would of course try to make sure every external thing used by the program is in a well known state, with an appropriate setup and good administration e.g.. The qoutes can be found in both the Minix book and Modern OSs, security chapters. - georg running Debian GNU/Linux most of the time.