Re: How to activate MAC address randomization?





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.


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



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]