linux-kernel - Re: [PATCH] bridge: make it possible for packets to traverse the bridge withour hitting netfilter

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] [day] [month] [year] [list]

Date:	Mon, 23 Feb 2015 16:24:22 +0100
From:	Imre Palik <imrep.amz@...il.com>
To:	Florian Westphal <fw@...len.de>
CC:	David Miller <davem@...emloft.net>,
	bridge@...ts.linux-foundation.org, stephen@...workplumber.org,
	netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
	imrep@...zon.de, aliguori@...zon.com
Subject: Re: [PATCH] bridge: make it possible for packets to traverse the
 bridge withour hitting netfilter

On 02/13/15 20:03, Florian Westphal wrote:
> Imre Palik <imrep.amz@...il.com> wrote:
>> The trouble is that there are some bridges (with low traffic) where I need netfilter, and some other bridges (carrying lots of traffic), where I don't.  Being able to set things up on a per bridge basis is a powerful thing.
>>
>> I only implemented the global switch because the iptables and arptables support also have one.  If this is what bugs people here, I can remove it, and resubmit.
> 
> I see.  But I agree with David, accepting such patch would pave way
> for all kinds of ugly hacks.
> 
> It seems that technically the best solution would be to allow attaching
> filter rules to devices, but alas, netfilter doesn't support that.
> 
> Alternatively, you patch *might* be ok iff you can get rid of the extra
> userspace-visible configuration knobs, we already have way too many of
> these.

The sysctl can be removed.  But I need some means to switch it off for a given bridge, so I kept the sysfs interface.
If there is a more preferred way to do it, then please let me know.

> You'll also have to figure out how to avoid any run-time dependency on
> br_netfilter module from the bridge core.
> 
> If you can do this, you might be able to get similar effect as your patch
> by replacing
> 
> NF_HOOK with NF_HOOK_COND(..., !(br->flags & NO_NETFILTER))
> 
> or something like this.

This works nicely for the NFPROTO_BRIDGE, NF_BR_PRE_ROUTING case.  Thanks for the idea.
But for the NFPROTO_BRIDGE, NF_BR_FORWARD case the resulting code would be more ugly,
because of the chaining of the entries.

> I don't know how invasive this would be, though.

I will post the cleaned up version in a sec.
It looks way better.   I hope it will be enough ...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/