LWN.net Logo

RE: [PATCH 1/3] Rough VJ Channel Implementation - vj_core.patch

From:  Rusty Russell <rusty-AT-rustcorp.com.au>
To:  Caitlin Bestler <caitlinb-AT-broadcom.com>
Subject:  RE: [PATCH 1/3] Rough VJ Channel Implementation - vj_core.patch
Date:  Thu, 27 Apr 2006 13:40:26 +1000
Cc:  "David S. Miller" <davem-AT-davemloft.net>, kelly-AT-au1.ibm.com, netdev-AT-vger.kernel.org
Archive-link:  Article, Thread

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...

Cheers,
Rusty.
-- 
 ccontrol: http://ozlabs.org/~rusty/ccontrol

-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html



(Log in to post comments)

Copyright © 2006, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds