Getting rid of the root account

Anton Rang rang at cpsin3.cps.msu.edu
Wed Jun 7 09:06:08 AEST 1989


In article <10370 at smoke.BRL.MIL> gwyn at brl.arpa (Doug Gwyn) writes:
>In article <16638 at rpp386.Dallas.TX.US> jfh at 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.  [ stuff about layers ]
>  More
>elaborate kernel hooks make it harder to be sure there are no loopholes.

Why?  If you have a layered security system, every part of it must be
validated.  It's no easier than putting it in the kernel.  What's
more, if you have a single privilege, you have to ensure that EVERY
operation you do is provably secure.  I doubt this is doable with
existing validation mechanisms.

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

This can be done (well, approximated) much more easily if you have a
large number of distinct privileges.  If a section of code is running
with, say, "GROUP" privilege (under VMS, this gives access to other
processes in the group, and allows access to group data structures),
you don't need to worry that a call to open a file will read a
protected file.  With monolithic privilege, any privileged code could
do this.
  I've done some (little) work on security validation.  It's not easy.
Monolithic privilege schemes don't help at all.

+---------------------------+------------------------+
| Anton Rang (grad student) | "VMS Forever!"         |
| Michigan State University | rang at cpswh.cps.msu.edu |
+---------------------------+------------------------+



More information about the Comp.unix.wizards mailing list