Path: utzoo!attcan!lsuc!ecicrl!eci386!jmm
From: jmm@eci386.uucp (John Macdonald)
Newsgroups: comp.unix.wizards
Subject: Re: Getting rid of the root account
Message-ID: <1989Jun8.210946.26746@eci386.uucp>
Date: 8 Jun 89 21:09:46 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> <16650@rpp386.Dallas.TX.US>
Reply-To: jmm@eci386.UUCP (John Macdonald)
Organization: R. H. Lathwell Associates: Elegant Communications, Inc.
Lines: 65

In article <16650@rpp386.Dallas.TX.US> jfh@rpp386.cactus.org (John F. Haugh II) writes:
>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.
>
> [ and more ]

Not all SUID programs are SUID to root!  The people who are arguing that
the *kernel* requires many different permission variants seem to have
missed this point.  Unix (from v1 on through all less historical variants)
provides the SUID mechanism which permits implementation of permission
variants without any kernel knowledge of the meaning or interrelation
of the variants.  Thus you can have uucp-permission, or lpr-permission,
or bin-permission.  If you want a system that is proveably secure, you:

1. get rid of all root logins from the normal /etc/passwd
2. get rid of all suid-root programs that have not been fully verified
3. create suid-<category> programs to manage privelged activities for
    each different <category> you need.  You may need to write (and prove
    correct) a suid-root permission management program for complicated
    cases.

For the system maintenance functions that require root privileges, you
either prove correct the maintenance programs that are needed, or you
reboot the system, staying in single-user mode, using a different
/etc/passwd file from what is normally used is multi-user mode.  Put an
armed guard at the console full-time to prevent unauthorized use of this
hole in security.

This setup allows the kernel to be proved since there is not a huge amount
of requirement - it must not give out root permission gratitously, it must
implement suid correctly.  It allows any site to configure its own security
requirements without having to make any change to the kernel.  It allows the
typical system be sold as reasonably secure without the high expense of proof
which satisfies needs of most systems[1].

It puts the cost of proving or validating any additional security needs on
those people who require and implement those needs.  This does not preclude
providing some programs which do some of these tasks either with the system,
or in any other fashion (comp.unix.sources); but people who *require*
security will have to validate such programs anyhow.

    [1] Flames about the "reasonably secure" phrase above are not really
    required - I am aware of the fact that most Unixes, as delivered,
    and as later manipulated, are not perfectly secure; but they are
    good enough for most non-military purposes - most sites would not be
    willing to pay an extra $10K [for example] to get a secure version of
    their system that was otherwise identical.