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
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,
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
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
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-
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.
>
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
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
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
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
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
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
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
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
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
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
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
17 matches
Mail list logo