[ On Wednesday, December 5, 2001 at 22:50:29 (-0500), Rick Byers wrote: ]
> Subject: Re: upgrading ipfilter (was: patch for limiting MSS)
>
> Forgive my ignorance, but why is the use of an LKM not advisable in a
> secure environment? 

The ability to dynamically load code that will execute with superuser
privileges, especially kernel code, is always fraught with danger.

The first published demonstration that I know of the dangers of LKMs in
particular was in Phrack Magazine Volume 7, Issue 51; Sept. 1, 1997.  I
understand that since then there have been versions of this hack written
for Solaris and perhaps for other systems too.

> If someone has permission on my machine to replace my
> lkm (i.e. root), then they can pretty much do whatever they want anyway.

Indeed -- but with an LKM they can bypass most kinds of integrity
checking tools you might use, including even tripwire reading it's
database from read-only media.  That was the main thrust of the Phrack
article, but of course once you've loaded hidden code into the kernel
you can pretty much do anything you want.

> If the ability to unload an lkm and load a hacked one is really seen as a
> security threat (since it doesn't require rebooting like loading a new
> kernel does), then we should have a secure-level setting which prevents
> lkms from being unloaded or something to that effect.

We do.  I don't trust it, and it doesn't solve the (perhaps unsolvable)
problem of securely checking the integrity of the LKM modules in a
closed system.

>  Of course, I see
> the problem with lkms on diskless machines, but thats another story...

Isn't it ever!  ;-)

Note that lkms aren't the only thing you have to watch out for when
running machines diskless.  There have been demonstrations of hacks
which modify code (i.e. introduce trojans) for any privileged program as
it's being read over the network (i.e. spoofing the NFS server).  I
don't think this works with NFSv3 over TCP, but I'm sure there are other
hacks possible!  ;-)

> Of course, all of this is a bit of a hack due to a lack of a versioned
> interface.  That would be the ideal solution, but probably overly complex
> and a big headache (atleast from the bits of ipf code I've looked at).

yeah...

-- 
								Greg A. Woods

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