|| ||Rusty Russell <rusty-AT-rustcorp.com.au>|
|| ||Caitlin Bestler <caitlinb-AT-broadcom.com>|
|| ||RE: [PATCH 1/3] Rough VJ Channel Implementation - vj_core.patch|
|| ||Thu, 27 Apr 2006 13:40:26 +1000|
|| ||"David S. Miller" <davem-AT-davemloft.net>, kelly-AT-au1.ibm.com,
On Wed, 2006-04-26 at 12:30 -0700, Caitlin Bestler wrote:
> David S. Miller wrote:
> > I personally think allowing sockets to trump firewall rules
> > is an acceptable relaxation of the rules in order to simplify
> > the implementation.
> I agree. I have never seen a set of netfilter rules that
> would block arbitrary packets *within* an established connection.
Intelligent or no, this does happen. More importantly, people rely on
packet counters. Basically I don't think we can "relax" our firewall
implementation and retain trust 8(
I started thinking about this back in January. We could force
everything through the "slow" path when something is registered with
netfilter (similarly raw sockets, bonding, divert). Or, we could delay
LOCAL_IN hook processing until we get to socket receive.
Delaying netfilter hook processing won't work for intelligent NICs that
write straight to mmapped buffers, but we could make that CAP_NET_RAW.
We *used* to have an nf_cache mechanism to determine exactly when the
netfilter hooks cared about a packet, but it was never used and was hard
to reconcile with connection-tracking timeouts...
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
to post comments)