Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!apple!sun-barr!cs.utexas.edu!csd4.milw.wisc.edu!srcsip!nic.MR.NET!hal!ncoast!allbery From: allbery@ncoast.ORG (Brandon S. Allbery) Newsgroups: comp.unix.wizards Subject: Re: Getting rid of the root account Message-ID: <13752@ncoast.ORG> Date: 14 Jun 89 22:57:23 GMT References: <10370@smoke.BRL.MIL> <16650@rpp386.Dallas.TX.US> <132@orchid.warwick.ac.uk> Reply-To: allbery@ncoast.ORG (Brandon S. Allbery) Followup-To: comp.unix.wizards Organization: Cleveland Public Access UN*X, Cleveland, Oh Lines: 65 As quoted from <132@orchid.warwick.ac.uk> by maujf@warwick.ac.uk (Mike Taylor): +--------------- | In article <16650@rpp386> jfh@rpp386.cactus.org (John F. Haugh II) writes: | > In article <10370@smoke.BRL.MIL> gwyn@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@ncoast.org uunet!hal.cwru.edu!ncoast!allbery ncoast!allbery@hal.cwru.edu Send comp.sources.misc submissions to comp-sources-misc@ NCoast Public Access UN*X - (216) 781-6201, 300/1200/2400 baud, login: makeuser