Bug 1387350 - NetworkManager started to change MAC address
Summary: NetworkManager started to change MAC address
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: NetworkManager
Version: 7.3
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: rc
: ---
Assignee: Thomas Haller
QA Contact: Desktop QE
URL:
Whiteboard:
: 1387421 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-10-20 16:50 UTC by Jaroslav Škarvada
Modified: 2017-07-25 10:04 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-07-25 10:04:42 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description Jaroslav Škarvada 2016-10-20 16:50:13 UTC
Description of problem:
This is probably related to [1]. The change was introduced in NetworkManager-1.2+ and got into RHEL-7.3. Now NetworkManager by default actively scans with random MAC and randomly change it during scanning. This is not only regression, but I think it shouldn't do it by default. I think that this behaviour is against standards and can increase probability of address collisions (because there can be clients the station doesn't here). It can also break "legacy" customers that relies on MAC ACLs.

I think that this "feature" only gives false feeling of increased privacy, as usually it's e.g. possible to quite well match clients according to SSIDs queries it does. I also think that in business environment any anti-identification / spoofing attempts are problematic and that it shouldn't be done by default in price of exploiting standards.

[1] https://blogs.gnome.org/thaller/2016/08/26/mac-address-spoofing-in-networkmanager-1-4-0

Version-Release number of selected component (if applicable):
NetworkManager-1.4.0-12.el7

How reproducible:
Always

Steps to Reproduce:
1. Check syslog

Actual results:
There are logs about setting random MAC

Expected results:
No MAC change with the default NetworkManager settings

Additional info:

Comment 3 Thomas Haller 2016-10-21 09:16:43 UTC
(In reply to Jaroslav Škarvada from comment #0)
> Description of problem:
> This is probably related to [1]. The change was introduced in
> NetworkManager-1.2+ and got into RHEL-7.3. Now NetworkManager by default
> actively scans with random MAC and randomly change it during scanning. This
> is not only regression, but I think it shouldn't do it by default. I think
> that this behaviour is against standards and can increase probability of
> address collisions (because there can be clients the station doesn't here).
> It can also break "legacy" customers that relies on MAC ACLs.

By default, NetworkManager now sets a random MAC addresss *during scanning*. When associating, the default is still to restore the permanent MAC address (though this is now configurable as well).


I don't think MAC ACLs matter *during scanning*. How would they?


Other operating systems do that as well, like IOS (though it seems not always: http://blog.mojonetworks.com/ios8-mac-randomization-analyzed/ ).


The probability of address collision is practically very low. First of all, the generated random MAC address has the locally-administered bit set (by default, again this is configurable). Thus, it should not conflict with a real, burned-in MAC address from an existing device.
Yes, it can happen that when you track the MAC addresses in your neighbor hood over a longer period, you encounter two random MAC addresses from different users. Thus, you see a MAC address collision. But that is precisely the feature, not the bug. Such tracking should become meaningless.
The chance that you encounter a MAC address collision in your Wi-Fi range at the same time, seems very low. And even you win that lottery, would it matter during scanning? If two devices accidentally decide to scan using the same MAC address, would that cause problem? (I don't think so). If you scan with a random MAC address that happens to collide with somebody who is associated using the same MAC address, would it disrupt the connectivity of that other person? (I don't think so either).



> I think that this "feature" only gives false feeling of increased privacy,
> as usually it's e.g. possible to quite well match clients according to SSIDs
> queries it does. I also think that in business environment any
> anti-identification / spoofing attempts are problematic and that it
> shouldn't be done by default in price of exploiting standards.

Nobody is claiming that this alone is able to entirely annonymize you. It just is one step away of broadcasting a unique Identifier about your computer into the air. Yes, if you associate later, by default we revert to the permanent MAC address (to avoid problems with captive portal and MAC ACLs). So yeah, the actual use certainly can be questioned. But the alternative of broadcasting your ID seems certainly worse privacy wise.

Do you see a standard that recommends *not* to spoof your MAC address during scanning? I am not aware of that.

You say "are problematic". But not exactly what the problem is there. You mean address collision and MAC ACLs? As said, I think that is not a real issue.


Looking forward to hear your further opinions. Thanks.

Comment 4 Thomas Haller 2016-10-21 09:25:30 UTC
*** Bug 1387421 has been marked as a duplicate of this bug. ***

Comment 5 Dalibor Pospíšil 2016-10-21 09:36:21 UTC
I see an issue in output of ip a or ip l. The address is changed frequently which is usually not expected by users/admins. I think this is not good default for enterprise systems.
If such system is meant to be 'spying' neighbourhood and still keep its identity hidden, then it should be explicitly enabled.

Comment 7 Thomas Haller 2016-10-21 09:52:30 UTC
the actual change in default is trivial to revert.


We would just install a configuration snippet

  /usr/lib/NetworkManager/conf.d/00-no-wifi-scan-rand-mac-address.conf

with

  [device]
  wifi.scan-rand-mac-address=0



Note, a user who dislikes the new behavior, can disable it the same why, by putting above configuration snippet to /etc/NetworkManager/conf.d.




We changed behavior intentionally, and it is considered a feature, not a bug/regression. It seems, that should be re-evaluated, discussed, and possibly reverted.

Comment 8 Jaroslav Škarvada 2016-10-21 12:00:47 UTC
(In reply to Thomas Haller from comment #3)
> (In reply to Jaroslav Škarvada from comment #0)
> > Description of problem:
> > This is probably related to [1]. The change was introduced in
> > NetworkManager-1.2+ and got into RHEL-7.3. Now NetworkManager by default
> > actively scans with random MAC and randomly change it during scanning. This
> > is not only regression, but I think it shouldn't do it by default. I think
> > that this behaviour is against standards and can increase probability of
> > address collisions (because there can be clients the station doesn't here).
> > It can also break "legacy" customers that relies on MAC ACLs.
> 
> By default, NetworkManager now sets a random MAC addresss *during scanning*.
> When associating, the default is still to restore the permanent MAC address
> (though this is now configurable as well).
> 
> 
> I don't think MAC ACLs matter *during scanning*. How would they?

What is exactly meant by scanning? If SSID is visible (which usually should be), it can passively listen to SSID broadcasts, it don't need any MAC.

Regarding MAC ACLs, I think that for hidden SSIDs, the probes can be technically filtered as well.

> 
> 
> Other operating systems do that as well, like IOS (though it seems not
> always: http://blog.mojonetworks.com/ios8-mac-randomization-analyzed/ ).
>
That Apple devices do it sometimes as well isn't valid argument especially for enterprise class distribution.
 
> 
> The probability of address collision is practically very low. First of all,
> the generated random MAC address has the locally-administered bit set (by
> default, again this is configurable). Thus, it should not conflict with a
> real, burned-in MAC address from an existing device.
> Yes, it can happen that when you track the MAC addresses in your neighbor
> hood over a longer period, you encounter two random MAC addresses from
> different users. Thus, you see a MAC address collision. But that is
> precisely the feature, not the bug. Such tracking should become meaningless.
> The chance that you encounter a MAC address collision in your Wi-Fi range at
> the same time, seems very low. And even you win that lottery, would it
> matter during scanning? If two devices accidentally decide to scan using the
> same MAC address, would that cause problem? (I don't think so). If you scan
> with a random MAC address that happens to collide with somebody who is
> associated using the same MAC address, would it disrupt the connectivity of
> that other person? (I don't think so either).
>
Thinking that it doesn't affect interoperability/connectivity isn't valid argument for introduction of this behaviour into stable enterprise product.


> 
> 
> > I think that this "feature" only gives false feeling of increased privacy,
> > as usually it's e.g. possible to quite well match clients according to SSIDs
> > queries it does. I also think that in business environment any
> > anti-identification / spoofing attempts are problematic and that it
> > shouldn't be done by default in price of exploiting standards.
> 
> Nobody is claiming that this alone is able to entirely annonymize you. It
> just is one step away of broadcasting a unique Identifier about your
> computer into the air. Yes, if you associate later, by default we revert to
> the permanent MAC address (to avoid problems with captive portal and MAC
> ACLs). So yeah, the actual use certainly can be questioned. But the
> alternative of broadcasting your ID seems certainly worse privacy wise.
> 
> Do you see a standard that recommends *not* to spoof your MAC address during
> scanning? I am not aware of that.
> 
I don't have the standards handy, nor I am feeling like expert in this field, but I am pretty sure no standard recommends address spoofing. E.g. IEEE Std 802-2001, chapter 9.2.1 which is introducing MAC addresses concept:

"The concept of universal addressing is based on the idea that all potential members of a network need to have a unique identifier (if they are going to coexist in the network). The advantage of a universal address is that a station  with  such  an address can  be attached to  any LAN  in the world  with  an assurance that the address is unique."

For your randomly generated addresses it's not assured there are unique. I am pretty sure there are more in the standards against your approach.

> You say "are problematic". But not exactly what the problem is there. You
> mean address collision and MAC ACLs? As said, I think that is not a real
> issue.
> 

I am not against introduction of this "feature" into NetworkManager (despite whatever I mean about it's usefulness), I am against that it was enabled by default in the stable enterprise product. Was there any customer requirement? Business reason? Bugzilla? Interoperability testing?

Comment 9 Francesco Giudici 2016-11-02 12:34:23 UTC
Hi Jaroslav

(In reply to Jaroslav Škarvada from comment #8)

> What is exactly meant by scanning? If SSID is visible (which usually should
> be), it can passively listen to SSID broadcasts, it don't need any MAC.

Active scanning is used by default in all OSes I'm aware of to speed up the process of retrieving the neighboring WiFi networks. For each channel, the wireless device sends a probe request and gets probe responses from APs.
With passive scanning you should instead wait on EACH channel for at least 100ms to get the beacons from APs. It would require too much time to be practical.

WiFi MAC randomization is applied by default to probe requests only.
What you probably find annoying is that when your wifi is disconnected you see your mac address changing time to time (and never be the "real" one).
This is the "issue" we are talking about, right?

> 
> Regarding MAC ACLs, I think that for hidden SSIDs, the probes can be
> technically filtered as well.
> 

Well, I don't think that probe requests for hidden SSIDs would be filtered by the ACL... but if also this would happen, well, I think would be not that bad, warning the customer of a potential security issue (hidden SSID + MAC ACL is not considered secure at all).

> > 
> > 
> > Other operating systems do that as well, like IOS (though it seems not
> > always: http://blog.mojonetworks.com/ios8-mac-randomization-analyzed/ ).
> >
> That Apple devices do it sometimes as well isn't valid argument especially
> for enterprise class distribution.

True, but on the other side this means that this behavior is not new and is quite widespread. I think this was the point from Thomas.

>  
> > 
> > The probability of address collision is practically very low. First of all,
> > the generated random MAC address has the locally-administered bit set (by
> > default, again this is configurable). Thus, it should not conflict with a
> > real, burned-in MAC address from an existing device.
> > Yes, it can happen that when you track the MAC addresses in your neighbor
> > hood over a longer period, you encounter two random MAC addresses from
> > different users. Thus, you see a MAC address collision. But that is
> > precisely the feature, not the bug. Such tracking should become meaningless.
> > The chance that you encounter a MAC address collision in your Wi-Fi range at
> > the same time, seems very low. And even you win that lottery, would it
> > matter during scanning? If two devices accidentally decide to scan using the
> > same MAC address, would that cause problem? (I don't think so). If you scan
> > with a random MAC address that happens to collide with somebody who is
> > associated using the same MAC address, would it disrupt the connectivity of
> > that other person? (I don't think so either).
> >
> Thinking that it doesn't affect interoperability/connectivity isn't valid
> argument for introduction of this behaviour into stable enterprise product.
> 
> 
> > 
> > 
> > > I think that this "feature" only gives false feeling of increased privacy,
> > > as usually it's e.g. possible to quite well match clients according to SSIDs
> > > queries it does. I also think that in business environment any
> > > anti-identification / spoofing attempts are problematic and that it
> > > shouldn't be done by default in price of exploiting standards.
> > 
> > Nobody is claiming that this alone is able to entirely annonymize you. It
> > just is one step away of broadcasting a unique Identifier about your
> > computer into the air. Yes, if you associate later, by default we revert to
> > the permanent MAC address (to avoid problems with captive portal and MAC
> > ACLs). So yeah, the actual use certainly can be questioned. But the
> > alternative of broadcasting your ID seems certainly worse privacy wise.
> > 
> > Do you see a standard that recommends *not* to spoof your MAC address during
> > scanning? I am not aware of that.
> > 
> I don't have the standards handy, nor I am feeling like expert in this
> field, but I am pretty sure no standard recommends address spoofing.
> .... <snip> ....

Well, probably not yet. But a new IEEE group has been formed in 2014 to address privacy issues: the IEEE 802 Privacy Executive Committee (EC) Study Group.
In the IEEE End to End Trust and Security Workshop for the Internet of Things held this year in Washington DC, one of the talks addressed MAC randomization and other techniques to enforce privacy. Here some relevant slides:
https://standards.ieee.org/events/iot/presentations/ieee_e2e_trust_and_security_workshop_for_iot_-_wi-fi_privacy.pdf

So, come on, saying MAC randomization is against the standards seems a little bit strong... I would rather say there are no ratified standard yet, but the process is ongoing, toward MAC randomization direction and beyond.

> 
> I am not against introduction of this "feature" into NetworkManager (despite
> whatever I mean about it's usefulness), I am against that it was enabled by
> default in the stable enterprise product. Was there any customer
> requirement? Business reason? Bugzilla? Interoperability testing?

Well, I think we can sum up all in two main points:
(1) does this randomization change harm?
(2) why probe request MAC randomization has been made the default instead to stick to previous behavior?

I think the answer to (1) here is no. Please, if you really think there is something real against (1), tell.
Regarding point (2), I am in favor of keeping MAC randomization in probe requests... but I think that we must first all agree on (1) before moving to discussing (2), which IMO is a legitimate question.

Comment 11 Peter Backes 2017-07-17 08:23:15 UTC
This is also a problem on Fedora 25, NetworkManager-1.4.4-5.fc25.i686

Comment 12 Thomas Haller 2017-07-17 09:44:17 UTC
(In reply to Peter Backes from comment #11)
> This is also a problem on Fedora 25, NetworkManager-1.4.4-5.fc25.i686

Yes, that behavior is also in Fedora 25.

But what is the precise problem with it?

Comment 13 Peter Backes 2017-07-17 09:55:39 UTC
(In reply to Thomas Haller from comment #12)
> Yes, that behavior is also in Fedora 25.
> 
> But what is the precise problem with it?

I understand that it adds to privacy and should be on by default, but when I right-click the NetworkManager tray icon, I expect a checkbox "Enable randomized MAC scanning" right next to "Enable Wi-Fi" where I can turn it off.

Comment 14 Thomas Haller 2017-07-17 10:15:01 UTC
(In reply to Peter Backes from comment #13)
> (In reply to Thomas Haller from comment #12)
> > Yes, that behavior is also in Fedora 25.
> > 
> > But what is the precise problem with it?
> 
> I understand that it adds to privacy and should be on by default, but when I
> right-click the NetworkManager tray icon, I expect a checkbox "Enable
> randomized MAC scanning" right next to "Enable Wi-Fi" where I can turn it
> off.

There is no GUI option to do that, nor is it easy to add -- because the GUI is usually concerned with connection (profiles), while this is a per-device setting. That means, it is independent from a connection profile because the randomization during scanning happens before you are connected to any profile.

The question is why do you want to disable it and what problems does it cause for you.

Comment 15 Thomas Haller 2017-07-25 10:04:42 UTC
I am closing this as WONTFIX.

We already changed behavior with rhel-7.3, which is out of the door now for several months. So, this bug asks for a revert of the behavior change, restoring the previous default.

As discussed, the change to enable randomization was done intentionally, because we think it is beneficial for most users without hurting them (which of course is disputed on this bug).




This change was more painful on Fedora/Ubuntu, because NetworkManager broke with some out-of-tree-drivers (which are not supported in RHEL) [1]. In the meantime (nm-1-8, rhel-7.4), NetworkManager improved here and it should also work well with those drivers (bug 1382741).

Also, there was a race in supplicant when changing the MAC address. This is fixed with rhel-7.4 too (bug 1447073).

So, NM in rhel-7.4, some glitches were fixed, but the 7.3 behavior is kept.


In our opinion, this bug report does not sufficiently explain what the actual problem is with changing the MAC address during scanning. Please re-open if you can provide a new argument. Thanks.


[1] https://bugzilla.gnome.org/show_bug.cgi?id=777523


Note You need to log in before you can comment on or make changes to this bug.