[By the way, apologies for the bounced mail last night -- I'm attempting
 something that I thought I knew how to do but it's not working...]

Rules on physical access:

	If the person has physical access to the console, security
	becomes difficult.

	If the person has physical access to the *machine*, security
	approaches impossible.

The only way to retain functionality and security in the described
scenario would be to hack a password input scheme into the kernel.
Once you do that, its weaknesses will be exploited ("we need better
password protection at boot time" and so on) and the kernel will
begin to grow.

On Wed, 26 Dec 2001, Ignatios Souvatzis wrote:

# Date: Wed, 26 Dec 2001 18:37:46 +0100
# From: Ignatios Souvatzis <is@netbsd.org>
# To: der Mouse <mouse@Rodents.Montreal.QC.CA>
# Cc: tech-userlevel@netbsd.org
# Subject: Re: RFC: migration to a fully dynamically linked system
#
# On Wed, Dec 26, 2001 at 08:21:55AM -0500, der Mouse wrote:
# > > As to /sbin/init; there's a couple of solutions:
# > [...]
# > > 	  Provide /sbin/init.static and/or /recovery/sbin/static
# > > 	  (see below for more info about recovery options), and add
# > > 	  those paths to the list of paths (listpaths[]) that
# > > 	  sys/kern/init_main.c::start_init() tries to exec.
# >
# > You mean the kernel still has a hardwired list of paths?  Ages ago I
# > added code so that if the exec of init fails, or if an option
# > (RB_INITPATH) is provided by the MD boot code, it prompts for a
# > pathname for init.
#
# Hm... doesn't Linux provide some similar functionality, resulting in instant
# root access (for the knowledgable) in Linux-equipped student workstation
# pools? Of course, it's hard (nearly impossible) to secure a machine with
# semi-public physical access...
#
# Regards,
# 	-is
#


				--*greywolf;
--
NetBSD: "Progress on your system is closer than it appears."