On Wed, 5 Dec 2001, Greg A. Woods wrote:

> > Couldn't ipf be loaded from an lkm so that the lkm and userland could be
> > easily kept in sync?
>
> It could, if you are not worried about LKM's in general (and presumably
> if you're running ipfilter on even a -current kernel then you are either
> doing development on it, in which case an LKM is OK, or you're using it
> to protect your system in which case use of a LKM is perhaps not
> advisable), but that doesn't really solve the problem.  You have to
> update the ipfilter user tools and ipfilter kernel code in sync,
> regardless of how the latter is loaded/linked into the kernel you run.

But if we arranged to install the lkm at the same time the userland
binaries were installed (i.e. happens as part of the make process in
/usr/src/usr.sbin/ipf), then - for most people anyway - it would work
seamlessly.  Atleast the way I normally update my system is to build a new
kernel, reboot, build userland, reboot (to get any changes to init etc.).
At the very least, it would give the user some control - allow them to
select the old ipf kernel code until they've had a chance to rebuild the
userland.

Forgive my ignorance, but why is the use of an LKM not advisable in a
secure environment?  If someone has permission on my machine to replace my
lkm (i.e. root), then they can pretty much do whatever they want anyway.
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.  Of course, I see
the problem with lkms on diskless machines, but thats another story...

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

Rick