Re: security

[thompson jeffrey w <jwthomp @ cs . uiuc . edu>]

> mcnabb @
 argus .
 cu-online .
 com (Paul McNabb) writes:
> >Whoa, there!  If the operating system is not "secure" then there is no
> >guarantee that any program running on that OS is functioning properly.
> 
> 	The guarantee boils down to "we coded the program well"
> which is, basically, the same "guarantee" that the "secure" operating
> system gives. Really, the discussion is academic, since sooner or
> later you are going to have to rely on fallible humans to get
> something imporant coded correctly. This applies all the way down
> to the chips in the box - code is code whether it's C, silicon, or
> solder.*

    Actually, the problem here is that if an operating system is not secure
then there is no guarantee that the applications running on it can be "trusted".
This has little to do with whether a program was coded "well", but whether
you can trust that the program remains "well". Actually, it is very important
to secure the base, as without it even the most secure application will not
hold up. (Beware the power of uid 0) 

> 	Don't look at the fictional "guarantees" provided at
> any level in the system: look at the leverage provided by getting
> as much as possible right at the lowest possible level. If your
> chips are reasonably well designed then the operating system
> running on them can rely on the MMU to silently work its magic.
> If the operating system is reasonably well coded then the
> applications running on it can rely on it to work its magic by
> giving them virtual machine address spaces, etc, etc. If the
> applications were coded reasonably well then the network
> administrator can rely on them to act as a reasonable network
> firewall.

There is a difference between having a program run functionally well, and
it being secure.

> 	At every point, each part of the system relies on the
> guarantees made to it by the ones below it. Sometimes the
> guarantees are false, often they are not. But at every point
> in the system you're relying on human-generated code.

This is why you have other humans verify your work.  Preferably those with
some knowledge of the issues which will affect your code.  (security, proper
functionality)

Jeff Thompson

Jeff Thompson(jwthomp @
 uiuc .
 edu)        Argus Systems Group
http://www.uiuc.edu/ph/www/jwthomp      - Trusted Network Kernel Developer
ACM at UIUC Vice Chair / SigNET Chair  Member *The Guild