[ On Wednesday, December 5, 2001 at 23:24:49 (-0000), David Laight wrote: ]
> Subject: Re: upgrading ipfilter (was: patch for limiting MSS)
>
> The loadable driver is no more likely to be compromised than the file
> containing the filter rules....

perhaps....

The real issue is figuring out what's under attack in such a scenario.
Attacking the rules might be rather less rewarding and more risky to the
attacker than attacking the kernel, as it has been shown quite
dramatically that a successful attack on the kernel leaves you unable to
even detect the intrusion (at least not without using a completely
separate system to try to carefully analyse the system disk off-line),
so not only is the payback higher for attacking the kernel, but the risk
of getting caught is far lower too.

> Not if the interface to the updated filter code is binary compatible
> with the old version.  Maybe the 'new' userspace programs know how to
> load the 'new' or 'old' drivers, possibly with different rules....

Currently the APIs for ipf(4), ipl(4), and ipnat(4) are not versioned.
Any change to the ioctl()s or the structures they pass makes the ABI
incompatible, regardless of whether anything else uses /dev/kmem or not.
I.e. yes, now, at this minute, you must update the ipfilter user tools
and ipfilter kernel code in sync, regardless of how the latter is
loaded/linked into the kernel you run.

> (greg - check the ipfstat man page, one of them uses kmem...) 

Yeah, well "ipfstat" isn't really that critical to the functioning of
ipfilter, and use of /dev/kmem could relatively easily be eliminated by
simply enhancing the API for ipl(4) (or which ever other virtual device
makes sense).

In fact there's already SIOCGETFS, and if I'm not mistaken it wouldn't
take too much more (something to recursively get 'struct frentry'
elements) to reimplement "ipfstat" without using /dev/kmem.

If I'm not mistaken "ipnat"s only use of /dev/kmem is also for printing
state and stats, not for its basic function of loading the tables, and
similarly that could be migrated to an ioctl().

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