[ On Friday, August 23, 2002 at 14:38:32 (-0400), Gary Thorpe wrote: ]
> Subject: Re: Where to put firmware?
>
> In other words, modularity = bad. 

Well, yes, but only run-time modularity is bad, and only when it
involves code that will run at, or might be able to obtain, enhanced
privileges.  All code in any unix-like kernel is always able to run at
the highest possible level of privilege

Even more insidiously code running in the kernel can very effectively
hide itself from all but the most careful examination by even the most
privileged user.  Additional hardware support is often required to
detect a compromise of a running kernel.  The code in kernel mode is its
own "god" and can create whatever reality it wishes.  Once your kernel
is compromised you won't ever even be able to know it, under "normal"
circumstances.

> However, since root can acess kernel memory via
> /dev/kmem, how can lkms be much less secure? Anyone
> who has access to root and can load lkms can do
> equally nasty things even without lkm.

That's not true in cases where it matters.

/dev/kmem cannot be written to by any process when the kernel
securelevel is one or greater, and it would be relativley easy to
implement a level where it cannot even be read (with of course the
corresponding reduction of functionality).

> A single kernel binary image can be compromised at
> boot time as well.

Of course it can -- that's why I addressed the reason why multiple files
are more of a risk.

I've been very carefully studying this issue since the late 1980's when
I first discovered that my 3B2's static-linked kernel image was
generated by booting the system in a configuration mode where it
dynamically loaded _all_ kernel modules and then optionally wrote out
the file image of a static-linked kernel containing the desired modules
and desired pre-startup configuration settings (eg. proc and file table
sizes, etc., etc.).  I anticipated even then that a carefully crafted
foreign module could lay in wait for such a configuration boot and then
hide itself and all past evidence of how it came to be, even from the
likes of tripwire using secure read-only integrity databases.  Such
modules have since been created and described for *BSD and Solaris (and
probably other platforms as well), and they don't even have to wait for
a re-configuration boot -- they'll get loaded on every boot and they can
only be discovered by analyzing the affected boot disk from a secured
system that's been booted from a known safe disk (eg. boot and run
everything from a safe CD-ROM).

> Does NetBSD's boot loader use
> password protection etc.?

No, not the default one shipped with the official code.

Certain assumptions can be made true about physical security though, and
about the mandatory audit checks for every reboot, etc.

-- 
								Greg A. Woods

+1 416 218-0098;            <g.a.woods@ieee.org>;           <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>