On Wed, 2016-05-18 at 21:10 -0400, Chris Laprise wrote: > > On 05/18/2016 02:25 PM, Dan Williams wrote: > > > > > > Randomization happens in the supplicant, and the supplicant also > > controls scanning. If randomization is enabled, the supplicant > > will > > change the MAC address before it scans, so this should not be a > > problem. > > > > Of course, if you run 'iw dev wlan0 scan' manually, that does not > > go > > through the supplicant, and you will leak your MAC. > > > > If you use NM's MAC cloning functionality, then yes, that might > > leak > > your MAC because that only clones the MAC address for the duration > > of > > the connection to a specific access point. It's not randomization, > > it's the same as ethernet MAC cloning. > It does seem like a primary use case for randomization would be > random > addresses during scans only, and transition to chosen non-original > addresses for connections (per-AP). The users and admins aren't going > to > think to themselves: "We're going to assign different addresses to > these > connections, so we're OK with the hardware address coming through." > Not > if they're using pre-connection randomization (which should be > considered the operational norm by now). > > And its not that connection randomization isn't important, too. I > just > think that pre-connection randomization would work very well towards > privacy if the 'randomization' were on a per-AP basis and not a > per-session basis (the latter being less compatible with some > institutional security schemes). Per-AP is more realistic and far > more > likely to be used. > > So I would like to know if NM can coordinate with supplicant well > enough > to transition the NIC between randomized pre-connection scanning and > statically-spoofed connections without allowing the original address > to > be broadcast.
NM always requests that non-associated scans (eg, before you've connected to a wifi network) be randomized by default. You can (through the mac randomization property) request that the association address also be randomized. You can also use the cloned MAC address property to set a specific MAC address for the association, on a per-connection basis. If you choose "always" for mac randomization, that overrides the cloned mac address. As far as we know, and as far as we've tested, these both work correctly when wpa_supplicant support exists and the driver uses the nl80211 kernel API. Out-of-tree and WEXT-based drivers may not work correctly. There does seem to be some confusion about the issue as you can see from this thread, so we're trying to investigate that and clear things up. But when the features were added, they worked. Dan > > > > > If you're looking for a more generic MAC randomization feature that > > also works for ethernet, then yes that would be NM's > > responsibility. > > Internally NM would handle ethernet MAC randomization itself, but > > delegate to the supplicant for WiFi. Since the supplicant handles > > scanning, it must also handle WiFi MAC randomization to ensure > > synchronization of the changes. > > > > Dan > Ethernet is probably not as pressing a concern because of the > physical > link aspect, but thanks for the insight. > > Chris > _______________________________________________ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
