Date: Thu, 23 Apr 1998 20:44:05 +1000 (EST) From: darrenr@reed.wattle.id.au To: eivind@yes.no (Eivind Eklund) Cc: hackers@FreeBSD.ORG Subject: changing ipfw interface (was Re: cvs commit: src/sys/netinet ip_fw.c) Message-ID: <9804231048.AA01717@avalon.reed.wattle.id.au.> In-Reply-To: <19980423015125.15103@follo.net> from "Eivind Eklund" at Apr 23, 98 01:51:25 am
next in thread | previous in thread | raw e-mail | index | archive | help
In some email I received from Eivind Eklund, sie wrote: > > On Thu, Apr 23, 1998 at 01:50:05AM +1000, darrenr@reed.wattle.id.au wrote: > > In some email I received from Eivind Eklund, sie wrote: > > > > > > That's what I'm saying - it blow the userland interface. It means > > > that anything using IPFW has to track the kernel version exactly. > > > > There are numerous programs like this already - ps, netstat, top, etc. > > > > I'd say "deal with it". > > ps et.al. aren't that critical. Sure, it suck that they are that > way, but if ps is broken, _you can still get to the machine_. This is > not the case with IPFW. Having a structure-dependent interface for > the firewall is IMO not acceptable. Then maybe ipfw is `being handled wrongly'. You have code which lives in the kernel that must interface with the userland *tightly*. That entire bundle must stay consistant with respect to versions. It's not so much dependant on the kernel version, but rather you're changing the "ipfw" version when you change the kernel or user code. For what it's worth, using ipfw as an LKM (which isn't compiled out of /sys) maybe what you're really thinking of here although then your kernel security drops. Actually, I'm not sure what you're proposing makes any difference unless you're planning on using BPF to write ipfw rules, as the interface becomes `programmable' (along with the bloat required in the kernel to support it unless that's not a factor in your requirements). Well, that's my opinion, although I get the impression you're of a different mind. If you disagree, well I agree to disagree for now, until I see more details and can make a better decision. I'm not saying I don't want to discuss the above, however. Darren p.s. redirecting to hackers@... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9804231048.AA01717>