netdev - Re: [PATCH] bridge: make bridge-nf-call-*tables default configurable

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4A4B965B.4070700@trash.net>
Date:	Wed, 01 Jul 2009 19:01:15 +0200
From:	Patrick McHardy <kaber@...sh.net>
To:	Herbert Xu <herbert@...dor.apana.org.au>
CC:	Mark McLoughlin <markmc@...hat.com>,
	netdev <netdev@...r.kernel.org>,
	"David S. Miller" <davem@...emloft.net>
Subject: Re: [PATCH] bridge: make bridge-nf-call-*tables default	configurable

Herbert Xu wrote:
> On Wed, Jul 01, 2009 at 11:21:44AM +0200, Patrick McHardy wrote:
>> Agreed, at least as long as this is still the default behaviour.
>> Mark, could you add this to your patch? br_nf_pre_routing_finish()
>> looks like a good place to print a warning when skb->nfct != NULL.
> 
> Here's a suggestion:
> 
> Can we add another field to the conntrack tuple? This would be used
> to ensure that every bridge's conntrack is distinct from each other,
> as well as that of the system IP stack.

We would need a key that can be uniquely determined at all points
and that can be inverted (taking into account ebtables NAT, NAT to
a different bridge etc) - I can't think of a suitable one right now.
But besides the conntrack size increase, I don't think this is the
correct solution for this problem.

Defragmentation (before conntrack) would still allow fragments to
cross boundaries, unless we key the defragmentation queues using the
same key. And generally defragmenting bridged packets by default,
possibly passing them through NAT, IP routing etc. is simply wrong
and only (somewhat) works in certain scenarios. Helpers might get
confused when the same packet is flooded to multiple output ports,
IPsec policies might magically get applied, etc etc. The best way
to make people aware of all these implications and avoid unsuspecting
people running into this again and again would be to change the
defaults and have people think before they use this. Long term I
think this needs to be completely redesigned.

And for the record, I don't believe that this is used a lot and we're
just not aware because it simply works. The fact is it always had major
problems that we fixed as good as possible over the years, but I'm
pretty certain I've heard from just about every user of this at least
once :)

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