[ On Thu, October 8, 1998 at 18:28:03 (-0700), Curt Sampson wrote: ]
> Subject: Re: Another changer, another changer problem
>
> On Thu, 8 Oct 1998, Greg A. Woods wrote:
> 
> > > So? What I said still applies; I don't want my console going to
> > > just any terminal; I want it going only to physically secured
> > > terminal.
> > 
> > So?  Then mark the device file where this rogue user would poke the tty
> > port information into the PROM's NVRAM as immutable....
> 
> Actually, this is something that has to be fixed in the kernel (if
> the prom is accessed through something other than /dev/mem). However:

I was thinking of /dev/eeprom, actually, but whatever -- do something to
fix the access point if you want to protect it.

> I don't understand where the PROM comes in here. If you type
> `shutdown' on a NetBSD system you will, in the course of a few
> moments, get a single-user prompt on the console. The PROM is not
> involved.

I wasn't talking about shutdown to single user mode, I was talking about
a full reboot with potential pause in single user mode before multi-user
proceeds.  Jeez!  Pay attention Curt!

The PROM gets involved because that's what we were originally talking
about:  how do you *reboot* from remote safely if you might need to do a
re-configuration reboot?

Why else would I have been belaboring the point about setting the new
console definition for the PROM and wondering how/why someone would want
to hand an existing TCP/IP circuit off to the PROM?

I only suggested "shutdown" as one of the places where this hook could
presumably be implemented -- you jumped to the false conclusion that
this would mean a plain shutdown to single user mode would frag your
console and give a remote hacker access to it.

Which comes back to the reason why I suggested protecting the NVRAM
settings, preventing mknod() and maybe even preventing reboot(), because
unless you do it matters not where the hook is implemented.  If you make
the NVRAM settings immutable at securelevel >= 2 then nobody's going to
frag your console settings, so find something else to worry about.
However if NVRAM is modified through some special device then you've got
to protect either the driver for that device (ala the way /dev/mem is
already protected), and/or prevent the rogue root from making a new
special file that's not marked immutable (thus the reason for preventing
mknod()).

Unless you prevent root from killing processes then a rogue root's going
to be able to emulate single user mode anyway -- the only difference is
they'll have to crack the securelevel settings to get very far.  So long
as the only way to change securelevel is to raise it (which is the only
sane way it can be implemented safely) then the rogue root still has to
go through a reboot() call and if you are successful in applying all
necessary protective measures this will be a fruitless endeavor because
the system will just come right back up and enter securelevel >= 2
again.

See?  My console reassignment trick hasn't thwarted you in the least and
yet it would allow me to have a local physical console as well as
another connected to a modem or some secure terminal server, etc.  For
example on my sparstation I could normally have it set to the keyboard,
but with a modem on ttya I could do a full system reset from remote.
Naturally with eeprom(8) I can probably do this now on my sparc, but
it's a kludge and I have to remember to reset things manually too.
Putting the hooks in the right places just makes it "foolproof".

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>