Getting rid of the root account

[Brandon S. Allbery]

As quoted from <132 at orchid.warwick.ac.uk> by maujf at warwick.ac.uk (Mike Taylor):
+---------------
| In article <16650 at rpp386> jfh at rpp386.cactus.org (John F. Haugh II) writes:
| > In article <10370 at smoke.BRL.MIL> gwyn at brl.arpa (Doug Gwyn) writes:
| >> 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.
| 
| You keep saying this.  The point is, _it's_not_the_kernel's_fault!_
| Just because a lot of people have written insecure utilities and
| persuaded other people to  make them setuid root, doesn't make the
| fundamental system insecure -- it just makes the people stupid, and
| that really _isn't_ news! :-)
+---------------

Agreed -- you can misuse any privilege system to make a system insecure.
The best possible collection of privileges is worthless if you give every
yser and program all privileges....

Someone was moaning about how /etc/mount ought relinquish all privileges
except when it absolutely need them, to "simplify verification".  Fine --
except that it needs multiple abusable privileges (i.e. file read/write) most
of the time.  And you must verify that it does in fact release its
privileges when it's not using them, i.e. that it doesn't call a library
routine which grabs file write privileges and doesn't release them.

The proper solution can be done with (BSD-style) Unix as it is.  I specify
BSD-style because you need multiple groups to be useful, although it is
certainly possible to "newgrp" around to get privileges, and requiring this
might make the certifiers happier.

/etc/mount:  setuid root(0), mounts the named filesystem, executable only by
owner (root) and group mount or wheel or etc.  It *might* update a file
readable/writeable only by the group; in that case, it can let go of its
setuid after it has performed the mount.

/etc/umount:  Same as above, except unmounts.

/etc/mounts:  Might be setgid mount if you want anyone to be able to execute
it.  All it does is format and print the file updated by /etc/mount and
/etc/umount; for this, it does not need root privileges, just group
privileges.  For higher security, don't make it setgid and limit its
execution to group mount.

If you omit the file update, you have limited each program to a single
specific and easily verifiable function.  You can then implement the file
update in a second program which has permissions only to perform that
function; this gets you easily-verified programs via Unix's setuid/setgid
and Unix's ability to easily perform complex operations with small programs
instead of monoliths, born of (relatively) cheap process creation.

Secure Unix *is* possible; it just requires a re-think of most of the
utilities.  Since they all have to be re-thought anyway to meet *any*
security classification, may as well go whole-hog and do it right.

++Brandon
-- 
Brandon S. Allbery, moderator of comp.sources.misc	     allbery at ncoast.org
uunet!hal.cwru.edu!ncoast!allbery		    ncoast!allbery at hal.cwru.edu
      Send comp.sources.misc submissions to comp-sources-misc@<backbone>
NCoast Public Access UN*X - (216) 781-6201, 300/1200/2400 baud, login: makeuser