Re: [Bridge] xt_physdev has no effect if net.bridge.bridge-nf-call-iptables=0

Hi! Here is a fix for the problem I've reported yesterday. http://marc.info/?l=netfilter-devel&m=132555432331663&w=2 Please review the patch carefully, I'm not a br_netfilter ninja. 8-) Thanks, //richard ___ Bridge mailing list Bridge@lists.linux-fou

[Bridge] [PATCH] netfilter: Fix br_nf_pre_routing() in conjunction with bridge-nf-call-ip(6)tables=0

If net.bridge.bridge-nf-call-iptables or net.bridge.bridge-nf-call-ip6tables are set to zero xt_physdev has no effect because skb->nf_bridge has not been set up. Signed-off-by: Richard Weinberger --- net/bridge/br_netfilter.c | 31 +++ 1 files changed,

Re: [Bridge] [PATCH] netfilter: Fix br_nf_pre_routing() in conjunction with bridge-nf-call-ip(6)tables=0

Am 03.01.2012 17:15, schrieb Stephen Hemminger: > On Tue, 3 Jan 2012 14:26:04 +0100 > Richard Weinberger wrote: > >> If net.bridge.bridge-nf-call-iptables or net.bridge.bridge-nf-call-ip6tables >> are set to zero xt_physdev has no effect because skb->nf_bridge

Re: [Bridge] [PATCH] netfilter: Fix br_nf_pre_routing() in conjunction with bridge-nf-call-ip(6)tables=0

Am 03.01.2012 21:15, schrieb Bart De Schuymer: > The documentation is probably not explicit enough, but I would keep the > behavior as it is now. Setting bridge-nf-call-iptables to 0 makes > iptables behave as if bridge-netfilter was not enabled at compilation. > Anyway, your patch is almost certai

Re: [Bridge] [PATCH] netfilter: Fix br_nf_pre_routing() in conjunction with bridge-nf-call-ip(6)tables=0

Am 04.01.2012 18:55, schrieb Bart De Schuymer: > Op 3/01/2012 21:29, Richard Weinberger schreef: >> Am 03.01.2012 21:15, schrieb Bart De Schuymer: >>> The documentation is probably not explicit enough, but I would keep the >>> behavior as it is now. Setting bridge-

Re: [Bridge] [PATCH] netfilter: Fix br_nf_pre_routing() in conjunction with bridge-nf-call-ip(6)tables=0

Am 05.01.2012 20:50, schrieb Bart De Schuymer: > Op 5/01/2012 0:13, Richard Weinberger schreef: >> >> Let's export brnf_call_iptables and brnf_call_ip6tables, such that >> physdev_mt_check() can notify the user that his iptables rule will have >> no effect. >

[Bridge] user controllable usermodehelper in br_stp_if.c

Hi! By spawning new network and user namesapces an unprivileged user is able to execute /sbin/bridge-stp within the initial mount namespace with global root rights. While this cannot directly be used to break out of a container or gain global root rights it could be used by exploit writers as valu

Re: [Bridge] [PATCH net] bridge: Only call /sbin/bridge-stp for the initial network namespace

Am 30.11.2015 um 22:38 schrieb Eric W. Biederman: > > There is no defined mechanism to pass network namespace information > into /sbin/bridge-stp therefore don't even try to invoke it except > for bridge devices in the initial network namespace. > > It is possible for unprivileged users to cause

Re: [Bridge] user controllable usermodehelper in br_stp_if.c

Am 30.11.2015 um 21:14 schrieb Kees Cook: > On Sun, Nov 29, 2015 at 2:43 PM, Richard Weinberger wrote: >> Hi! >> >> By spawning new network and user namesapces an unprivileged user >> is able to execute /sbin/bridge-stp within the initial mount namespace >> with

Re: [Bridge] [PATCH 1/1] bridge: remove BR_GROUPFWD_RESTRICTED for arbitrary forwarding of reserved addresses

Florian, Am Montag, 1. Oktober 2018, 18:24:25 CEST schrieb Florian Fainelli: > If all you are doing is forwarding anything, one thing I experimented > with before is the following: > > # tc qdisc add dev eth1 handle : ingress > # tc qdisc add dev eth3 handle : ingress > # tc filter add de

Re: [Bridge] [PATCH 1/1] bridge: remove BR_GROUPFWD_RESTRICTED for arbitrary forwarding of reserved addresses

Am Montag, 1. Oktober 2018, 20:25:26 CEST schrieb Ido Schimmel: > On Mon, Oct 01, 2018 at 08:16:22PM +0200, Richard Weinberger wrote: > > Florian, > > > > Am Montag, 1. Oktober 2018, 18:24:25 CEST schrieb Florian Fainelli: > > > If all you are doing is fo

Re: [Bridge] [PATCH 1/1] bridge: remove BR_GROUPFWD_RESTRICTED for arbitrary forwarding of reserved addresses

Am Montag, 1. Oktober 2018, 20:48:21 CEST schrieb Ido Schimmel: > > This is my plan b, having a u32 classifier that transports STP directly > > to the other interface. > > But IMHO this all is a bit hacky and a "forward anything" bridge mode > > sounds more natural to me. > > But "forwarding STP a

Re: [Bridge] [PATCH 1/1] bridge: remove BR_GROUPFWD_RESTRICTED for arbitrary forwarding of reserved addresses

Am Montag, 1. Oktober 2018, 21:04:33 CEST schrieb Ido Schimmel: > On Mon, Oct 01, 2018 at 08:54:08PM +0200, Richard Weinberger wrote: > > So the only option is having a bridge and transport STP via tc-mirred > > or patching the bridge code (what we do right now). > > And

Re: [Bridge] [PATCH 1/1] bridge: remove BR_GROUPFWD_RESTRICTED for arbitrary forwarding of reserved addresses

Nikolay, Am Dienstag, 2. Oktober 2018, 16:59:31 CEST schrieb Nikolay Aleksandrov: > Richard please check commit: > commit 5af48b59f35c > Author: Nikolay Aleksandrov > Date: Wed Sep 27 16:12:44 2017 +0300 > > net: bridge: add per-port group_fwd_mask with less restrictions > > We ne

Re: [Bridge] [PATCH 1/1] bridge: remove BR_GROUPFWD_RESTRICTED for arbitrary forwarding of reserved addresses

On Tue, Oct 2, 2018 at 6:48 PM Nikolay Aleksandrov wrote: > > Is there a reason why this knob is not documented in > > Documentation/ABI/testing/sysfs-class-net? > > > > Hmm, I don't think any of the bridge knobs are documented there or any other > master device for that > matter. Most of these

Bridge port userspace events broken?

Hi! My userspace needs /sys/class/net/eth0/brport/group_fwd_mask, so I set up udev rules to wait for the sysfs file. Without luck. Also "udevadm monitor" does not show any event related to /sys/class/net/eth0/brport when I assign eth0 to a bridge. First I thought that the bridge code just misses

Re: Bridge port userspace events broken?

Roopa, Nikolay, - Ursprüngliche Mail - > +1, this can be fixedbut in general all new bridge and link > attributes have better support with netlink. > In this case its IFLA_BRPORT_GROUP_FWD_MASK link attribute available > via ip monitor or bridge monitor. > you probably cannot use it w