netdev - Re: [PATCH 1/3 v3] net: usb: r8152: Check used MAC passthrough address

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: <ec2aaeb0-995e-0259-7eca-892d0c878e19@amd.com>
Date:   Tue, 11 Jan 2022 08:57:39 -0600
From:   "Limonciello, Mario" <mario.limonciello@....com>
To:     Kai-Heng Feng <kai.heng.feng@...onical.com>,
        Jakub Kicinski <kuba@...nel.org>
Cc:     Andrew Lunn <andrew@...n.ch>, Oliver Neukum <oneukum@...e.com>,
        Aaron Ma <aaron.ma@...onical.com>, henning.schild@...mens.com,
        linux-usb@...r.kernel.org, netdev@...r.kernel.org,
        davem@...emloft.net, hayeswang@...ltek.com, tiwai@...e.de
Subject: Re: [PATCH 1/3 v3] net: usb: r8152: Check used MAC passthrough
 address

On 1/10/2022 19:51, Kai-Heng Feng wrote:
> [+Cc Mario Limonciello, the original author on MAC pass-through]
> 
> On Tue, Jan 11, 2022 at 12:51 AM Jakub Kicinski <kuba@...nel.org> wrote:
>>
>> On Mon, 10 Jan 2022 11:32:16 +0800 Kai-Heng Feng wrote:
>>>>> I don't think it's a good idea. On my laptop,
>>>>> systemd-udev-settle.service can add extra 5~10 seconds boot time
>>>>> delay.
>>>>> Furthermore, the external NIC in question is in a USB/Thunderbolt
>>>>> dock, it can present pre-boot, or it can be hotplugged at any time.
>>>>
>>>> IIUC our guess is that this feature used for NAC and IEEE 802.1X.
>>>> In that case someone is already provisioning certificates to all
>>>> the machines, and must provide a config for all its interfaces.
>>>> It should be pretty simple to also put the right MAC address override
>>>> in the NetworkManager/systemd-networkd/whatever config, no?
>>>
>>> If that's really the case, why do major OEMs came up with MAC
>>> pass-through? Stupid may it be, I don't think it's a solution looking
>>> for problem.
>>
>> I don't know. Maybe due to a limitation in Windows? Maybe it's hard to
>> do in network manager, too, and we're not seeing something. Or perhaps
>> simply because they want to convince corporations to buy their
>> unreasonably expensive docks.
>>
>> What I do know is that we need to gain a good understanding of the
>> motivation before we push any more of such magic into the kernel.
> 
> Mario, do you know how corporate network and other OS handle MAC
> pass-through, so we can come up with a more robust design?

The important thing to remember is that many of these machines *don't*
have in-built network controller and rely upon a USB-c network adapter.

I recall a few reasons.

1) Consistency with the UEFI network stack and dual booting Windows when 
using the machine.  IOW 1 DHCP lease to one network controller, not one OS.

2) A (small) part of an onion that is network security.  It allows 
administrators to allow-list or block-list controllers.

The example I recall hearing is someone has their laptop stolen and 
notifies I/T.  I/T removes the MAC address of the pass through address
from the allow-list and now that laptop can't use any hotel cubes for 
accessing network resources.

3) Resource planning and management of hoteling resources.

For example allow facilities to monitor whether users are reserving and 
using the hoteling cubes they reserved.

> 
> Kai-Heng
> 
>>
>> I may be able to do some testing myself after the Omicron surge is over
>> in the US.