In some email I received from der Mouse, sie wrote:
[Charset iso-8859-1 unsupported, filtering to ASCII...]
> >>> And what happens if you say /bin/sh instead ?
> >> In most cases the user don't have control over what disks are in the
> >> machine, isn't it ?
> [someone else made a point about floppy and/or cdrom]
> 
> > Okay.  Given these concerns, which I admit have a valid point, the
> > successful exploit must be rely on the following:
> 
> > /tmp being a part of / or being able to write an exploit program to
> > somewhere inside the / filesystem as non-root.
> 
> No...not the / filesystem, but rather any local filesystem (well, any
> local filesystem that can be root - some local filesystem types have no
> mountroot capability).  If the attacker can boot with the option to
> prompt for init, the attacker can also specify arbitrary root device
> and kernel names.  Given this plus attacker write access to any
> filesystem the booter is willing to load the kernel from, the game is
> lost before "path to init?" even matters.

Now that I think about it, I don't believe it is possible to secure a
system where /sbin/init can be changed unless it is a standalone system
that has no home directories, does not use NFS, has no floppy/cdrom drive
and a bunch of other things, if console access is required.  i.e. it'd be
an xterminal (no local access at all).  The problem is that the earlier
questions (where is root, etc) allow for the trusted path (sic) to be
bypassed.  That said, the presence of the other questions makes it possible,
still, to gain root access to the box if you're at the console.

If there is to be a condition placed on the presence of the ability to
specify a different init other than /sbin/init because of security
requirements then that same condition should also be enforced on the
other questions which can also lead to a security breach (i.e. where is
the root filesystem).

There have been comments both in support of and against using an already
present option ("INSECURE") to toggle this behaviour.  At present, it
would seem to control the default value of securelevel and whether or not
the kernel will execute world writable files (lib/libsa/exec.c).  My first
thought here is to change "INSECURE" to control whether or not those
questions are asked at bootup, in addition to execution of world writeable
files and to add a new option, "SECURELEVEL" which is the default value
for securelevel - and that only.  Yes, this will `break' config files but
that would happen anyway, for someone.  Doing this change is a much larger
task but not insurmountable.

Comments ?

Darren