Installing 4.3-Tahoe on a VAX

[Dr. T. Andrews]

There are several ways to attack system security; becoming "root" is
surely one of the most obvious.  Protecting against this is certainly
a noble endeavour.

There is another possible problem, of course: the programme which
runs amok.  What?  You've never heard of bugs?

Finally: when something goes blooey (a user finds a hole in your
latest version of "priv_sys_hack", or a new bug in "df" tells it
to add random numbers to the free list), do you really want things
trashed?

My proposal, therefore, is that virtually NOTHING be owned by root.
Ownership by "bin" is adequate.  In many cases, it will be adequate
to assure that his /etc/passwd entry for the password is "*NOLOGIN*".
Provide a nice, empty list of "trusted" systems for him in network
environments.

Further, assure that you have no "setuid" programs (other than
perhaps the local replacement for "su").  Certain progs need to poke
around in /dev/kmem, /dev/disk, or whatever: provide them with a "set
group" bit (chmod 2111 /bin/df, &c.) and arrange that the progs be
owned uid=bin/group=sys.  The important files (/dev/kmem, /dev/disk,
&c.) should be owned by group "sys", and protected 0440.

Note the advantages of such a scheme (hello, AT&T; hello UCB; wakey,
wakey!  i've a nice cup of fish if you'll wake up, polly parrot):
	\(bu audit trail (see /etc/accton or local equiv) shows right
	  user id (no setuid prog to confuse issues)
	\(bu amok or buggy prog can't write to anything important
	\(bu you may arrange that no one is a member of group "sys"
	  and that the password is un-typable (try "*NOWHEELG*").
	\(bu certain dangerous things, not needed by most information
	  producing progs (eg: df, ps), require "root" privs.  if no
	  program has "root" privs, then your safety is increased
	  rather a lot.

In summary: there is really no excuse for most of the setuid "root"
progs which are distributed as part of unix.  Make them setgid "sys",
protect group "sys" reasonably, and eliminate the setuid "root"
progs.  The fact that most of them run setuid "root" is directly
related to laziness: no one needs to care about /dev/disk or /dev/kmem
if the program is setuid "root".

Certain directories will need to be created, and protected such that
group "sys" may scribble in them.  Consider that /usr/lib/ps may get
symbol table information which makes "ps" run faster the second time
that it is run.

Oh, yes, I advise that you protect things 0111: no sense letting J
Random Luser copy (or "strings" to see what looks like a promising
hole) everything.  Save disk space, prevent private copies, &c.
-- 
...!bikini.cis.ufl.edu!ki4pv!tanner  ...!bpa!cdin-1!cdis-1!ki4pv!tanner
or...  {allegra killer gatech!uflorida decvax!ucf-cs}!ki4pv!tanner