Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!execu!sequoia!rpp386!jfh
From: jfh@rpp386.Dallas.TX.US (John F. Haugh II)
Newsgroups: comp.unix.wizards
Subject: Re: Getting rid of the root account
Summary: Principle of Least Privilege.
Message-ID: <16650@rpp386.Dallas.TX.US>
Date: 8 Jun 89 02:36:18 GMT
References: <106326@sun.Eng.Sun.COM> <4315@ficc.uu.net> <16597@rpp386.Dallas.TX.US> <1961@ubu.warwick.UUCP> <16638@rpp386.Dallas.TX.US> <10370@smoke.BRL.MIL>
Reply-To: jfh@rpp386.cactus.org (John F. Haugh II)
Organization: River Parishes Programming, Plano TX
Lines: 65

In article <10370@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes:
>In article <16638@rpp386.Dallas.TX.US> jfh@rpp386.cactus.org (John F. Haugh II) writes:
>>Monolithic privilege is simple, elegant and neither secure nor
>>trustable.  Any single flaw in the privilege scheme may be exploited
>>to obtain complete privilege.
>
>To the contrary, the kernel implementation of UID 0 being the ONLY
>privileged UID along with the set-UID implementation is small and
>simple enough to be completely validated.

Agreed.  You may trivially verify that the suser() function performs
the desired result.  This is not news.

Now go verify that the utilities which execute with root privilege
perform their intended function.  The problem rapidly expands because
every program may potentially be run by root.  Turning off all of
the SUID programs may not do any good, if a bad guy [ as did happen
with a vendors secure product ] persuades root to execute an
unprivileged command.

You can't trust monolithic privilege.  Period.

>                                           That provides sufficient
>kernel support for layered implementation of more elaborate security
>schemes.

I really have to disagree, and I think the folks at NCSC agree with
me.  Secure and trustable kernels must be designed to be secure and
trustable - a trustable system is not going to be created by tacking
on another layer of cruft which must be verified for correctness.

>          You need to distinguish between the typical hodge-podge of
>user-mode privileged programs found on commercial UNIX systems and
>the inherent security hooks.  The latter make possible implementation
>of a provably secure, trustworthy multi-level security scheme.  More
>elaborate kernel hooks make it harder to be sure there are no loopholes.

I'm not certain I understand the argument, but I will argue that
simpler is not always better.

Consider - the existence of the mkdir() call complicates the kernel,
yet it removes the need for a root privileged program.  Recall Doug
Davis' mkdir hole?

Along the same vein, why should an installation program require
root privilege so it can create a few device files?  Wouldn't it be
more trustable if there were a privilege associated with creating
device files which granted no other special abilities?

>It doesn't matter what a "flaw" would mean if you can PROVE there are
>no flaws.

Part of the requirement for A1 is demonstrating that IF there are
flaws that the damage will be limited.

Monolithic privilege prevents this assurance.

Oh - I've yet to read a text on programming which ever stated that it
was possible to create a program of the size of an operating system
which has no bugs.
-- 
John F. Haugh II                        +-Button of the Week Club:-------------
VoiceNet: (512) 832-8832   Data: -8835  | "AIX is a three letter word,
InterNet: jfh@rpp386.Cactus.Org         |  and it's BLUE."
UucpNet : <backbone>!bigtex!rpp386!jfh  +--------------------------------------