Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!apple!well!nagle
From: nagle@well.UUCP (John Nagle)
Newsgroups: comp.unix.wizards
Subject: Re: Getting rid of the root account
Message-ID: <12654@well.UUCP>
Date: 11 Jul 89 18:58:35 GMT
References: <127@orchid.warwick.ac.uk> <16659@rpp386.Dallas.TX.US> <4499@ficc.uu.net> <1566@mcgill-vision.UUCP> <12148@bloom-beacon.MIT.EDU> <16734@rpp386.Dallas.TX.US>
Reply-To: nagle@well.UUCP (John Nagle)
Lines: 25

In article <16734@rpp386.Dallas.TX.US> jfh@rpp386.cactus.org (John F. Haugh II) writes:
>This problem of trusted programs executing non-trusted programs by
>accident causes UNIX to be inherently untrustable.  No trusted program
>should ever execute any untrusted program.  UNIX completely lacks this
>concept.

     It's worse than that.  No trusted program should even read non-trusted
data.  The distinction between program and data is not meaningful here; if
data can change the actions of a program, a security attack via that data
is possible.  Consider the worm attacks via the mail system, for example.

     Back in the Kernalized Secure Operating System days, we had the notion
of "integrity level" built into the system.  A process running at a high
integrity level cannot read data from a lower level.  This implies that when
one is running at "ADMINISTRATOR" integrity level, only "ADMINISTRATOR" level
files can be read or executed.  Lower level files can be written, though.
Low-integrity level programs cannot, of course, write high-integrity data,
although they can read it.
(The reverse applies to security level; you can move data up in security
level, but not down.  All files and processes had both.)

     It turns out to work, but it is a giant pain to operate under those
restrictions.  

					John Nagle