netdev - Re: [PATCH net-next 1/2] bridge: Add MAC Authentication Bypass (MAB) support

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:   Fri, 4 Nov 2022 13:11:05 +0000
From:   Vladimir Oltean <vladimir.oltean@....com>
To:     "netdev@...io-technology.com" <netdev@...io-technology.com>
CC:     Ido Schimmel <idosch@...dia.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "bridge@...ts.linux-foundation.org" 
        <bridge@...ts.linux-foundation.org>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "kuba@...nel.org" <kuba@...nel.org>,
        "pabeni@...hat.com" <pabeni@...hat.com>,
        "edumazet@...gle.com" <edumazet@...gle.com>,
        "roopa@...dia.com" <roopa@...dia.com>,
        "razor@...ckwall.org" <razor@...ckwall.org>,
        "mlxsw@...dia.com" <mlxsw@...dia.com>
Subject: Re: [PATCH net-next 1/2] bridge: Add MAC Authentication Bypass (MAB)
 support

On Fri, Nov 04, 2022 at 12:23:07PM +0100, netdev@...io-technology.com wrote:
> On 2022-11-04 00:18, Vladimir Oltean wrote:
> > > 3. Forwarding: Locked FDB entries forward traffic like regular entries.
> > >    If user space detects an unauthorized MAC behind a locked port and
> > >    wishes to prevent traffic with this MAC DA from reaching the host, it
> > >    can do so using tc or a different mechanism.
> > 
> > In other words, a user space MAB daemon has a lot of extra work to do.
> > I'm willing to bet it's going to cut 90% of those corners ;) anyway...
> 
> I would like to know your (Vladimir) take on the approach of the
> implementation for the mv88e6xxx that I have made and which will also be
> the basis for how the WesterMo hostapd fork will be afaik...
> 
> Is it in general a good idea to use TC filters for specific MACs instead
> of having the driver installing blocking entries, which I know the Marvell
> XCat switchcore will also have (switchcore installed blockig entries)?

Well, the mv88e6xxx driver does not offload tc filters in general, so
let's keep that in mind.

Achieving the behavior of not forwarding traffic to a BR_FDB_LOCKED
entry can be done in a variety of ways using tc. Simplest would be to
put an "action drop" filter on the egress chain of the port where the
BR_FDB_LOCKED entry is located. Although that's probably least amenable
to offloading. I think "action drop" is more popular as an offload
action on ingress chains, which means you'd either have to (a) put an
"action drop" on the ingress chain of every other bridge port, or
(b) create a shared tc block and put all bridge ports in that. The
problem with (b) is that it doesn't play all that well with bridge ports
belonging to different hardware blocks.

All in all, I think the yet-to-be-introduced 'blackhole' FDB flag makes
the most sense for this behavior. Its scope is the entire bridge
forwarding domain by definition (no need to attach it as filter to the
egress or ingress block of one/multiple bridge ports), and it's also
easily offloadable.

I think it could make a lot of sense for the MAB daemon to do one of 2
things: replace the BR_FDB_LOCKED entry with a static/dynamic FDB entry
if it's going to authorize it, or with a blackhole entry on br0 if it's
going to deny it. So you wouldn't have to manually add the blackhole
entry from the mv88e6xxx driver; user space would do it.