Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!uflorida!gatech!bbn!ulowell!hawk!arosen
From: arosen@hawk.ulowell.edu (MFHorn)
Newsgroups: comp.unix.wizards
Subject: Re: New (GNU) kernels--what I think
Keywords: UNIX progress; controversy
Message-ID: <13488@swan.ulowell.edu>
Date: 31 May 89 15:51:03 GMT
References: <2501@gandalf.UUCP>
Sender: news@swan.ulowell.edu
Reply-To: arosen@hawk.ulowell.edu (MFHorn)
Organization: University of Lowell, CS Dept
Lines: 29

In article <2501@gandalf.UUCP> ml@gandalf.UUCP (Marcus Leech) writes:
>Kernel:
>  Security should be improved by reducing the "granularity"
>  of priviledge.  That is, priviledged operations currently all require that
>  you are "root".  Perhaps there ought to be VMS-style privilege bits, or
>  perhaps just a reorganization of the kernel to allow various UIDs with
>  increasing levels of privilege.  VMS has too many privilege bits, UNIX has
>  too few.

VMS' problem isn't too many privilege bits, but that administrators make
too many accounts privileged.  I think having multiple privileged accounts
lowers security.  We have a large VAX with lots of accounts.  20 of them
have privileges in the ALL category.  I've got 20 username/password pairs
to attack.  Unix systems have 1 such pair.

A few months ago I put together a spec to implement privileges in Unix.
One of the design goals was to keep uid 0 from being magic.  I still wouldn't
recommend making any more than 1 account fully privileged.  The idea of the
privileges was to isolate all the privileged functions an administrator
performs, so that more accurate and controlled logging can be done.

(I can send anyone the spec who wants it.  Some day, I might even get the
resources to implement it ;-)

--
Andy Rosen           | arosen@hawk.ulowell.edu | "I got this guitar and I
ULowell, Box #3031   | ulowell!arosen          |  learned how to make it
Lowell, Ma 01854     |                         |  talk" -Thunder Road
		RD in '88 - The way it should've been