Re: software firewall wishlist (pf, but see systrace, which was a good idea, too)
Re: software firewall wishlist (pf, but see systrace, which was a good idea, too)
- Subject: Re: software firewall wishlist (pf, but see systrace, which was a good idea, too)
- From: "Christopher D. Lewis" <email@hidden>
- Date: Wed, 17 May 2006 16:42:28 -0500
On May 17, 2006, at 3:48 PM, Terry Lambert wrote:
This is not actually true. There are a number of approaches to
dealing with this, but taking over a single entry point rather than
muxing it is definitely *not* the way to play nice with other
software. Whatever approach you use *must* be amenable to being
daisy-chained.
The concern about leaving intact all the tools from other kits (altq,
NAT, etc.) is that if not replaced, software that doesn't know about
the pf-related system and how to interact with it will merely bollux
up the system rather than experience harmless but informative failure
(ie, the binaries that drive ipfw aren't there to be used, rather
than that they or a duplicate are there and pretend to do the right
thing but likely don't because of differences between the underlying
system and the userland tools by which they are driven and from which
one receives reports).
The idea behind the pf system is to give more power (per-connection
priority and not just per packet; address translation in the same
place as the filtering so that managing connections involving
translated IP addresses and redirections to different interfaces
don't do unexpected things; faster handling of complex rule sets;
genuine statefulness), and leaving alternate "solutions" for these
things risks enabling multiple inconsistent methods of skinning
various in-kernel cats, after the cat-breeder has gone to, say,
leapords. I can imagine why one might want to include wrappers for
folks who use tools that expect old FreeBSD parts to be there ... but
there won't be a 1:1 relation between what the pf system does and
what can be revealed by a old-compatible-lookalike wrapper. Where
confusion is the likely result of maintaining some semblance of
backward compatibility with prior tools, isn't clear and immediate
failure a better option?
Daisy-chaining works great with pf, just ... daisy-chaining a system
involving pf with tools that think they're talking to ipf, ipfw,
iptables, or the like is surely a road to madness, no?
Assuming this hasn't been rendered moot by source unavailability on
Apple's future platforms, is there an appropriate place to inquire
whether efforts to make security and administration improvements (eg:
pf, systrace) will be viewed favorably or will be rejected out of
hand and thus should not attract effort?
Best regards,
Chris
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden