Re: GNAT 3.14p and Red Hat 7.2

[Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de>]

Florian Weimer <fw@deneb.enyo.de> wrote:
: Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> 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.