[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ipf
On Wed, May 30, 2001 at 12:10:52AM -0500, Jeff Bachtel wrote:
> What would be the security advantage? Packet filters don't parse
> strings, or execve() programs, they filter. And thats it.
Well, in this day in age, people like to do other things than just
block according to the ip header details. Searching a packet data is
a popular request nowadays for people in search of a filewall.
> The reason you _don't_ put a packet filter in userspace is that a
> context switch is added for each packet that traverses the firewall.
Is the overhead of a context switch that much nowadays? If so, then
that's another area of work. The only real problem I see is the extra
copy of the packet in memory, which could be solved with an mmap()ed
interface (right??).
> And the only language to choose for a BSD packet filter is C. That is,
> if you want it to be capable of handling linespeed.
[ I won't bite on the language flamewar ]
> (in short, the only thing userland about a firewall should be the
> control programs)
I understand where you're coming from, but then again, your reasoning
is the same as Microsoft's reasoning for putting SMB into the NT kernel.
--
Michael Samuel <michael@miknet.net>
- Follow-Ups:
- Re: ipf
- From: Jeff Bachtel <sebastion@irelandmail.com>
- References:
- ipf
- From: Brian West <brian@bkw.org>
- Re: ipf
- From: Theo de Raadt <deraadt@cvs.openbsd.org>
- Re: ipf
- From: Michael Samuel <michael@miknet.net>
- Re: ipf
- From: Jeff Bachtel <sebastion@irelandmail.com>