Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!caen!uflorida!haven!decuac!hussar.dco.dec.com!mjr
From: mjr@hussar.dco.dec.com (Marcus J. Ranum)
Newsgroups: comp.sys.dec
Subject: Re: Summary: preventing dec3100 single user booting (protecting root)
Message-ID: <1990Nov29.221947.21056@decuac.dec.com>
Date: 29 Nov 90 22:19:47 GMT
References: <1990Nov27.211621.1501@zaphod.mps.ohio-state.edu> <161@raysnec.UUCP>
Sender: news@decuac.dec.com (Network News)
Organization: Digital Equipment Corp., Washington Ultrix Resource Center
Lines: 42

In article <161@raysnec.UUCP> shwake@raysnec.UUCP (Ray Shwake) writes:
>
>	Well, how about pushing vendors to design hardware interlocks that
>	prevent system boots, or disable terminal or keyboard response?

	What, like the "locks" on IBM PC/ATs ? The ones that can be
disabled instantly by unplugging a wire on the motherboard ?

>	Vendors installing identical locks on all systems such that anyone's
>	keys work on anyone else' system (don't laugh... some do it!) would
>	be subject to public shaming.

	I suppose you'd want the locks to somehow secure the cabinet as
well, to prevent jumpering the lock-switch. And maybe then we'd need to
add locking SCSI connectors, to prevent people from getting "root" by
booting off of a different system disk. We need a locking cover on the
tape drive, too, and so on, and so forth...

	Maybe a vendor who sells dup keys to their CPU (like IBM did)
would have cause to be ashamed - but a user who is naive enough to
place a great deal of trust in it should be ashamed, too. It is a
placebo and they fell for it.

	Even with shell-scripts protecting singleuser boots, you still
have to guard against spies who carry a spare SCSI shoebox around, and
daisy-chain the disk onto your system, boot off it, mount root, and
do Evil Things.

	The only system I ever saw that came close to solving these
issues was a package for PCs that encrypted the FAT and made the disk
unavailable until you cleared it with a password. Of course, when our
user (who had insisted this was necessary) finally lost the password,
I was able to grub around the disk with a disk-dumper and get the
data back anyhow. You'd have to just encrypt *everything* on the disk,
including the buffers in the bufcache, I suppose. :) - but I digress...

mjr.
-- 
	If your windowing system is placing undue demands on your hardware
and operating system, don't ask yourself what can be done to improve the
operating system or hardware - ask yourself why you are using that windowing
system.		[from the programming notebooks of a heretic, 1990]