Date: Thu, 16 Dec 2004 00:14:45 +0100 From: Andre Oppermann <andre@freebsd.org> To: Kelly Yancey <kbyanc@posi.net> Cc: freebsd-net@freebsd.org Subject: Re: per-interface packet filters [summary] Message-ID: <41C0C565.23D7053E@freebsd.org> References: <20041213124051.GB32719@cell.sick.ru> <20041213104200.A62152@xorpc.icir.org> <20041214015603.A75019@xorpc.icir.org> <20041214130712.GA46386@cell.sick.ru> <20041215154837.C46745@gateway.posi.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Kelly Yancey wrote: > > On Tue, 14 Dec 2004, Gleb Smirnoff wrote: > > > On Tue, Dec 14, 2004 at 01:47:35PM +0100, Andre Oppermann wrote: > > A> > Implementationwise, the kernel side is evidently trivial as the > > A> > original code already supports the idea of multiple chains. All > > A> > you need is to extend the struct ifnet with a pointer to the chain, > > A> > or use some other trick (e.g. going through ifindex) to quickly > > A> > associate a chain to the input (and possibly output) interface. > > A> > > A> Nonononononononononononononononononononononono. > > A> > > A> There MUST NOT be any firewall specific pointers or other information > > A> in struct ifnet or any other non-firewall private part of the kernel. > > A> Otherwise the entire independence we've gained with the nice and clean > > A> PFIL_HOOKS API goes down the drain. This MUST NOT happen again. > > A> > > A> The whole idea of the PFIL_HOOKS is to have independend and loadable > > A> firewall modules with different approaches, internal designs and so > > A> on. > > > > The whole idea of PFIL_HOOKS is to have independend and loadable firewall > > modules, which can be attached to different parts of kernel! There is no > > such requirement that, pfil hooks MUST be sticked to a single entry point > > in ip_input() and ip_output(). > > > > Pfils attached to interface belong to interface, and thus should be stored > > in struct ifnet. This is the way it is done in per-interface filters. > > > > A> For example a way Gleb can get his way without any bickering from us > > A> is by creating his own gleb-firewall module using the PFIL_HOOKS API > > A> and put it into the ports tree for easy access, provided he doesn't > > A> modify the PFIL_HOOKS API (which he doesn't have to). > > > > I am not going to create a new firewall or change PFIL_HOOKS. I'm going > > to attach *the existing* pfil_hooks to a different place, to perform > > filtering with *existing* firewalls. > > How about a generic per-interface pfil demultiplexer? That is, a module > that uses the existing pfil hooks to in turn call per-interface hooks. > As Luigi suggested earlier, it would be possible to use the interface > index to index an array private to the multiplexer's implementation. > If each element in this array had its own pfil_head, then the demultiplexer > could then call pfil_run_hooks() using that list. This would allow you > to have your per-interface hooks in a generic way without changing a line > of existing code. It could be entirely encapsulated in kld. Provided an > API to manipulate the per-interface pfil registration, you could even run > different filters on different interfaces. > You'de even have a chance of back-porting it to FreeBSD 5.x since you > won't be changing the ifnet structure at all. You'd have to change all firewall packages too. Currently they are not aware of and can't deal with multiple rule chain heads. The is the second main problem of Gleb implementation proposal so far. Nothing prevents generic routines to have the demultiplexer you describe but it's use and handling has to be inside each firewall package. -- Andre
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?41C0C565.23D7053E>