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 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.

> Personally I don't find anywhere near enough risk reduction in the
> lengths you're suggesting you might go to securing a system.

*Shrug*. You may not. On the other hand, thousands of warez kidz
with rootkits would disagree with you; this effectively stops them
from taking over a system without your knowledge at a not great
cost to the admin.

> All attempts to prevent the one and only superuser from doing
> super-user-like duties is only going to limit the usefulness of the
> system.  If you want multiple degrees of "super-user-ness" then you
> really need something slightly more complex than unix (Multics comes
> immediately to mind here...).

This is, again, your opinion. I have little difficulty with limiting
certain system activities to single-user mode. There are already
conditions on super-user like activities based on the state of a
system: you can't fsck a disk without it being unmounted, for
example, and can't fsck the root partition without being in
single-user mode and having it mounted read-only.

> So, if you're right then someone pulled of some minor magic and found a
> way to hand off a TCP connection to the PROM.

No. As I said above, there's no PROM involved when you just type
`shutdown' from multi-user mode.

> I.e. if you're interested in doing what you want to do then *you* have
> to do the extra work to take out the features you think are dangerous.

Right. Since you don't mind, you can configure your systems to run
at securelevel 0 and forget about it. It's *my* responsibility to
run at securelevel 2 and make the appropriate files immutable or
append-only. However, you appear to wish to take away my ability
to do even this.

cjs
--
Curt Sampson  <cjs@portal.ca>  604-257-9400    De gustibus, aut bene aut nihil.
Any opinions expressed are mine and mine alone.
The most widely ported operating system in the world: http://www.netbsd.org