*BSD News Article 63553


Return to BSD News archive

Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!news.mel.connect.com.au!munnari.OZ.AU!news.ecn.uoknor.edu!news.eng.convex.com!newshost.convex.com!cs.utexas.edu!not-for-mail
From: dhs@cs.utexas.edu (Douglas H. Steves)
Newsgroups: comp.os.linux.development.system,comp.os.linux.misc,comp.os.linux.networking,comp.unix.bsd.freebsd.misc,comp.unix.bsd.netbsd.misc,comp.unix.bsd.bsdi.misc
Subject: Re: need secure OS to entrust millions to
Date: 13 Mar 1996 13:30:47 -0600
Organization: CS Dept, University of Texas at Austin
Lines: 40
Message-ID: <4i77p7$rhu@nada.cs.utexas.edu>
References: <4gi6t6$3h9@lace.colorado.edu> <4gq2j9$2g48@babyhuey.cs.utexas.edu> <nhammond.3.00AE67CD@mindspring.com> <4htqvq$d5o@cobweb.aracnet.com>
NNTP-Posting-Host: nada.cs.utexas.edu
Xref: euryale.cc.adfa.oz.au comp.os.linux.development.system:19355 comp.os.linux.misc:91950 comp.os.linux.networking:31696 comp.unix.bsd.freebsd.misc:15455 comp.unix.bsd.netbsd.misc:2469 comp.unix.bsd.bsdi.misc:2654

In article <4htqvq$d5o@cobweb.aracnet.com>,
Brian Beattie <beattie@coyote.aracnet.com> wrote:
>Nick has a very good point and I agree with it that having a system with a
>defined level of assurance.  One that has been reviewed and tested by an 
>independent authority.  One that includes detailed documentation on the  
>"correct" operation is important.  Other than that no DoD level is better
>than standard UNIX security for "most" commercial applications.
>
>That said the assurance issue is a major one and for that reason alone
>I would steer clear of Free unixes, for applications requireing high
>assurance, unless you want to do the work required to have that assuracne.

I would question whether any vendor does the assurance necessary to
maintain their NCSC rating for their current, complete system. All
systems which I'm familiar with that have undergone NCSC evaluation
are backlevel, incomplete and usually incompatible versions of the
"real thing". And if they're not backlevel at the start of the 
evaluation, they are by the time the evaluation is complete.

While I would agree with you that the goals of the Orange Book
assurance requirements are laudable, their implemenation is suspect,
and leads to as many problems as their functional requirements.
I would rather buy a system from a vendor who cared a great deal
about security but cared nothing about the NCSC than an NCSC
certified system. Failing that, I want something with full sources
so that I can roll my own and so that others have had the 
opportunity to examine the system for bugs, trojan horses
and other things that go bump in the night.

>The rest of what Nick say about levels is pure gospel according to NCSEC
>and pretty much smoke and mirrors.  That is to say if your security can
>be breached at one level, it can probably be breached at any level.
I don't believe that this is quite the point he was making, but I
would agree with it - it is no harder to break into a multi-level
"secure" system at level X than it is at level Y. More to his point,
there is nothing that can be done with labels to restrict access than
cannot be done with other mechanisms, assuming a properly designed
acl scheme. So B level security really adds nothing here.

Doug