Path: utzoo!utgpu!utstat!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!mitel!sce!cognos!dgbt!gandalf!ml
From: ml@gandalf.UUCP (Marcus Leech)
Newsgroups: comp.unix.wizards
Subject: Re: New (GNU) kernels--what I think
Keywords: UNIX progress; controversy
Message-ID: <2511@gandalf.UUCP>
Date: 2 Jun 89 22:41:27 GMT
References: <2501@gandalf.UUCP> <13488@swan.ulowell.edu>
Organization: Gandalf Data Ltd, Product Development
Lines: 26

In article <13488@swan.ulowell.edu>, arosen@hawk.ulowell.edu (MFHorn) writes:
> 
> 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.
VMS really does have too many privilege bits--too much overlap in function,
  not enough justification for a given bits existence.  See Barry's posting
  in reply to me.
> 
> 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
I actually implemented an experimental version of the V7 kernel with privilege
  bits (and few other things like resource limits). I can't recall how many
  bits I had, or what they did. (I think there was a bit that controlled 
  whether or not you could run setuid programs, and whether you could
  execute the setuid() system call...).  I think a totally new model
  is needed.  I think that neither privilege bits, nor "magic" UIDs are
  the ultimate answer.
-- 
"Better Living through modern chemistry" PaperMail: 130 Colonnade Rd, Nepean,ON
Marcus Leech                             E-mail:     ml@gandalf.UUCP
Gandalf Data Ltd                         PacketRadio: VE3MDL@VE3JF
"The opinions expressed herein are solely my own" So there