Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!columbia!amsterdam!dupuy
From: dupuy@amsterdam.columbia.edu (Alexander Dupuy)
Newsgroups: comp.unix.questions
Subject: Security on Suns (was: Async terminal as console on a Sun)
Message-ID: <4946@columbia.edu>
Date: Wed, 26-Aug-87 17:58:34 EDT
Article-I.D.: columbia.4946
Posted: Wed Aug 26 17:58:34 1987
Date-Received: Fri, 28-Aug-87 06:45:47 EDT
References: <306@pvab.UUCP> <26419@sun.uucp> <4341@elroy.Jpl.Nasa.Gov>
Sender: nobody@columbia.edu
Reply-To: dupuy@amsterdam.columbia.edu (Alexander Dupuy)
Followup-To: comp.unix.questions
Organization: Columbia University Computer Science Dept.
Lines: 77

In article <4341@elroy.Jpl.Nasa.Gov> (David Robinson) writes:
>This brings up a problem that exists with Suns that I have.  The Suns
>are inherently insecure because anyone using a 3/50 can just
>power off the machine and reboot it in single user mode and become
>root.
>
[he suggests a hardware switch, like the lock on PC/ATs to remedy this]

While there will always be some vulnerability, there are a number of measures
which can be taken to give a reasonable amount of security for Suns, even
without physical security.

The primary vulnerability is that a Sun in an accessible place can be aborted
or power-cycled, and brought up in single-user mode.  This would give root
access (on the local machine only) to the intruder, allowing them to do
anything on that machine, and through staff ids, in some cases, to wreak some
havoc on other machines.

The first, and easiest, way to reduce the vulnerability of other machines is to
make sure that the vulnerable sun is not a trusted host (in /etc/hosts.equiv)
or trusted (in ~/.rhosts) by any users with special access to critical system
files.

There are also two ways to reduce the vulnerability of the publicly accessible
sun.  While it is practically impossible to prevent someone from power-cycling
the sun, or causing a cpu reset (abort), it is possible to reduce their ability
to bring the machine up in single user mode.

When a Sun comes up (whether in single- or multi- user mode) the first thing
/etc/init does is to run a script called /etc/rc.boot.  In this script, it is
possible to determine whether the machine is being brought up in single- or
multi- user mode.  A simple password checking program could be used to prevent
unauthorized single user boots.

[Sample from /etc/rc.boot:]

	if [ $1x = singleuserx ] && /bin/access
	then
	        (echo "Singleuser boot -- fsck not done")	>/dev/console
	else
		# fsck and go multi-user
	fi

[/bin/access uses getpass, crypt, getpwdent, etc. and is left as an exercise
 for the reader.]

Alternately, (or in addition to this) another approach can be taken.  After the
rc.boot script is finished, a root /bin/sh is started.  This (Bourne) shell
reads the file /.profile which can also tell whether this is a normal root
login, or a single-user boot.  In the latter case, a password check could be
enforced.

[Sample from /.profile]

	trap "" 1 3

	if [ "$USER" = "" ]; then		# singleuser boot
		if /bin/access
		then :
		else exec su nobody		# or something similar
		fi
	fi

While there are still methods of bypassing these checks, they are rather
obscure - bypassing the first relies on a feature which is incorrectly
documented to do something else (that may have been intentional...) and
bypassing the second is not always effective, (an intruder would have to try
several times) as it relies on interrupting the shell before the "trap".

So in summary, it is possible to make a Sun secure enough that only a person
with some Sun system admin experience would be able to bring it up single user
without authorization.

@alex
---
arpanet: dupuy@columbia.edu
uucp:	...!seismo!columbia!dupuy