Re: F40 Change Proposal: Wifi MAC Randomization (System Wide)
Kevin Kofler via devel writes: Sam Varshavchik wrote: > The ostensible reason for this is that you cannot be tracked by your fixed > MAC across different APs. But different APs will typically be operated by different people, who have no access to each other's MAC address logs anyway. So what is the point of sending them a different made-up MAC? I'm not advocating for it. I also think this is dumb. I'm just the messenger, this is just the argument for that. The threat vector is different APs that are covertly managed by the same entity. Geographically discrete APs that can be used to track the target using the target's fixed MAC address. Many SSIDs are well known, McDonals, etc… Presuming that the target's device knows the AP and auto-connects to the SSID a threat actor can covertly track the target by setting up rogue APs, in different geographic areas. > Yes, your visits to the same AP can still be tracked by that AP, but > that's as far as it goes. And the reason for using the same MAC with the > same AP is to still make it possible to do MAC address filtering. Sure, I understand that. But it is inherently impossible to allow MAC address filtering while blocking MAC address tracking. They are basically two use cases of the same thing. Not if the MAC is randomized per AP. The randomized MAC will remain fixed for that AP only, hence MAC filtering is still possible. pgprJ7caLS3Ao.pgp Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F40 Change Proposal: Wifi MAC Randomization (System Wide)
Leon Fauster via devel wrote: > https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/main/src/libnm-core-impl/nm-setting-wireless.c#L1598 So NM supports both, which leaves the question: Is the proposal to default to "stable-ssid" (or to "stable" with the stable-ID set to the SSID), or to plain "stable"? As explained in my other mail, "stable-ssid" is basically useless, whereas plain "stable" has the potential to break things (as Robert Nichols explained). Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F40 Change Proposal: Wifi MAC Randomization (System Wide)
Sam Varshavchik wrote: > The ostensible reason for this is that you cannot be tracked by your fixed > MAC across different APs. But different APs will typically be operated by different people, who have no access to each other's MAC address logs anyway. So what is the point of sending them a different made-up MAC? > Yes, your visits to the same AP can still be tracked by that AP, but > that's as far as it goes. And the reason for using the same MAC with the > same AP is to still make it possible to do MAC address filtering. Sure, I understand that. But it is inherently impossible to allow MAC address filtering while blocking MAC address tracking. They are basically two use cases of the same thing. For the randomization implementation, there are actually 2 possibilities to get a stable MAC per AP: hash the text SSID, or hash the BSSID. Which does NetworkManager use? The text SSID will be the same for all APs belonging to the same large network, so hashing with that will not prevent such large networks from tracking you, down to knowing pretty accurately where you are geographically (because they know which of their APs you connected to). Hashing the BSSID instead prevents that (unless the operator manages to spoof the same BSSID everywhere, which I guess you cannot really prevent on the client side either, though it will fail them if the AP's ranges overlap), but it also means that network-wide MAC address filtering will no longer work. Blocking tracking also blocks filtering, and the other way round. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F40 Change Proposal: Wifi MAC Randomization (System Wide)
Am 24.12.23 um 15:03 schrieb Robert Nichols: On 12/23/23 16:40, Sam Varshavchik wrote: Christopher Klooz writes: Btw, does anyone know if this (in the practically-same manner) is really already introduced in Windows, Mac, Android by default? Globally? This Most recent Android phones, and iPhones do this by default. What they do is pin each randomized MAC address per AP. They're not randomizing MACs for each connect, but basically generate a randomized MAC for each AP known to the phoneto spam, report it: https://pagure.io/fedora-infrastructure/new_issue I hope that's per SSID and not per AP, or else that would mean that as a device roams among access points in my network it would keep generating new MAC addresses that are not known to my DHCP server? https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/main/src/libnm-core-impl/nm-setting-wireless.c#L1598 It's bad enough that I can't know in advance what MAC address a new device will be using, and might thus have to decide which, of several possible DHCP requests that might appear, is the one to which I want to grant access. -- Leon -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F40 Change Proposal: Wifi MAC Randomization (System Wide)
On 12/23/23 16:40, Sam Varshavchik wrote: Christopher Klooz writes: Btw, does anyone know if this (in the practically-same manner) is really already introduced in Windows, Mac, Android by default? Globally? This Most recent Android phones, and iPhones do this by default. What they do is pin each randomized MAC address per AP. They're not randomizing MACs for each connect, but basically generate a randomized MAC for each AP known to the phoneto spam, report it: https://pagure.io/fedora-infrastructure/new_issue I hope that's per SSID and not per AP, or else that would mean that as a device roams among access points in my network it would keep generating new MAC addresses that are not known to my DHCP server? It's bad enough that I can't know in advance what MAC address a new device will be using, and might thus have to decide which, of several possible DHCP requests that might appear, is the one to which I want to grant access. -- Bob Nichols "NOSPAM" is really part of my email address. Do NOT delete it. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F40 Change Proposal: Wifi MAC Randomization (System Wide)
With regards to the related discourse topic #22 [1] (and my previous comment here): If this is introduced, what do you think of adjusting the starting page for F40 in Firefox? Most users tend to first check their Internet (and related issues) by opening their default browser and check if it works or if they can use their preferred search engine to search a solution: A small bold warning (and maybe a picture or two of how the problem manifests - e.g., the limited connectivity warning - to capture their attention) with a hint and a few pictures of which button to pull to disable the MAC randomization if they are affected negatively could be a good mitigation without increasing the stuff in the installer. [1] https://discussion.fedoraproject.org/t/f40-change-proposal-wifi-mac-randomization-system-wide/99856/22 On 24/12/2023 11.19, Christopher Klooz wrote: On 24/12/2023 04.45, Sam Varshavchik wrote: Kevin Kofler via devel writes: Sam Varshavchik wrote: > Christopher Klooz writes: > >> Btw, does anyone know if this (in the practically-same manner) is really >> already introduced in Windows, Mac, Android by default? Globally? This > > Most recent Android phones, and iPhones do this by default. > > What they do is pin each randomized MAC address per AP. They're not > randomizing MACs for each connect, but basically generate a randomized MAC > for each AP known to the phone. What is this actually good for? Any AP you connect to can still track you this way, and anything further uplink should not get your MAC address to begin with anyway (only your IP address). The ostensible reason for this is that you cannot be tracked by your fixed MAC across different APs. Yes, your visits to the same AP can still be tracked by that AP, but that's as far as it goes. And the reason for using the same MAC with the same AP is to still make it possible to do MAC address filtering. The majority of privacy issues when it comes to tracking take place on higher layers. The providers that are able to collect massive amounts of information about you have no access to your MAC. E.g., when using Google services. If a hotel chain can track me throughout its hotels, it can get more information than otherwise. However, they still get much less information than most web services that make money with tracking, especially since most is HTTPS today. There is an advantage with MAC randomization, but it is a small one, and I am not convinced if it is worth the efforts: for both developers and the users who have to handle some issues - or beginners who possibly end up in a "denial of service" because they have no idea what the problem is and how to respond (if people get a new notebook, those who use filtering for whitelists/blacklists or content filters for problematic content, e.g. if they have kids, will likely understand that something has to be done, but this proposal is not a case where a new notebook or so is introduced - thus, non-advanced users might not be able to understand WHAT to do and thus remain with the issue; some examples are in [1]). However, if there is a RFC that is already implemented by Apple, Microsoft and Android, I tend to change my mind and say let's keep consistency among operating systems: at least if the big three do it, I expect that vendors of hardware (for home routers and such) will respond to that also in favor of beginners (hopefully...). In any case, we then might at least ensure that users experience the issue on all systems roughly at the same time... That might serve as a small but existing mitigation. [1] https://discussion.fedoraproject.org/t/f40-change-proposal-wifi-mac-randomization-system-wide/99856/15 -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F40 Change Proposal: Wifi MAC Randomization (System Wide)
On 24/12/2023 04.45, Sam Varshavchik wrote: Kevin Kofler via devel writes: Sam Varshavchik wrote: > Christopher Klooz writes: > >> Btw, does anyone know if this (in the practically-same manner) is really >> already introduced in Windows, Mac, Android by default? Globally? This > > Most recent Android phones, and iPhones do this by default. > > What they do is pin each randomized MAC address per AP. They're not > randomizing MACs for each connect, but basically generate a randomized MAC > for each AP known to the phone. What is this actually good for? Any AP you connect to can still track you this way, and anything further uplink should not get your MAC address to begin with anyway (only your IP address). The ostensible reason for this is that you cannot be tracked by your fixed MAC across different APs. Yes, your visits to the same AP can still be tracked by that AP, but that's as far as it goes. And the reason for using the same MAC with the same AP is to still make it possible to do MAC address filtering. The majority of privacy issues when it comes to tracking take place on higher layers. The providers that are able to collect massive amounts of information about you have no access to your MAC. E.g., when using Google services. If a hotel chain can track me throughout its hotels, it can get more information than otherwise. However, they still get much less information than most web services that make money with tracking, especially since most is HTTPS today. There is an advantage with MAC randomization, but it is a small one, and I am not convinced if it is worth the efforts: for both developers and the users who have to handle some issues - or beginners who possibly end up in a "denial of service" because they have no idea what the problem is and how to respond (if people get a new notebook, those who use filtering for whitelists/blacklists or content filters for problematic content, e.g. if they have kids, will likely understand that something has to be done, but this proposal is not a case where a new notebook or so is introduced - thus, non-advanced users might not be able to understand WHAT to do and thus remain with the issue; some examples are in [1]). However, if there is a RFC that is already implemented by Apple, Microsoft and Android, I tend to change my mind and say let's keep consistency among operating systems: at least if the big three do it, I expect that vendors of hardware (for home routers and such) will respond to that also in favor of beginners (hopefully...). In any case, we then might at least ensure that users experience the issue on all systems roughly at the same time... That might serve as a small but existing mitigation. [1] https://discussion.fedoraproject.org/t/f40-change-proposal-wifi-mac-randomization-system-wide/99856/15 -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F40 Change Proposal: Wifi MAC Randomization (System Wide)
Kevin Kofler via devel writes: Sam Varshavchik wrote: > Christopher Klooz writes: > >> Btw, does anyone know if this (in the practically-same manner) is really >> already introduced in Windows, Mac, Android by default? Globally? This > > Most recent Android phones, and iPhones do this by default. > > What they do is pin each randomized MAC address per AP. They're not > randomizing MACs for each connect, but basically generate a randomized MAC > for each AP known to the phone. What is this actually good for? Any AP you connect to can still track you this way, and anything further uplink should not get your MAC address to begin with anyway (only your IP address). The ostensible reason for this is that you cannot be tracked by your fixed MAC across different APs. Yes, your visits to the same AP can still be tracked by that AP, but that's as far as it goes. And the reason for using the same MAC with the same AP is to still make it possible to do MAC address filtering. pgpsjgtOJxrI2.pgp Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F40 Change Proposal: Wifi MAC Randomization (System Wide)
Sam Varshavchik wrote: > Christopher Klooz writes: > >> Btw, does anyone know if this (in the practically-same manner) is really >> already introduced in Windows, Mac, Android by default? Globally? This > > Most recent Android phones, and iPhones do this by default. > > What they do is pin each randomized MAC address per AP. They're not > randomizing MACs for each connect, but basically generate a randomized MAC > for each AP known to the phone. What is this actually good for? Any AP you connect to can still track you this way, and anything further uplink should not get your MAC address to begin with anyway (only your IP address). Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F40 Change Proposal: Wifi MAC Randomization (System Wide)
Christopher Klooz writes: Btw, does anyone know if this (in the practically-same manner) is really already introduced in Windows, Mac, Android by default? Globally? This Most recent Android phones, and iPhones do this by default. What they do is pin each randomized MAC address per AP. They're not randomizing MACs for each connect, but basically generate a randomized MAC for each AP known to the phone. pgp8dkqPhfwm0.pgp Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F40 Change Proposal: Wifi MAC Randomization (System Wide)
On Sat, Dec 23, 2023 at 8:28 PM Christopher Klooz wrote: > Btw, does anyone know if this (in the practically-same manner) is really > already introduced in Windows, Mac, Android by default? There is a draft RFC for randomizing MAC addresses https://datatracker.ietf.org/doc/draft-ietf-madinas-mac-address-randomization/ which also has references for Windows, Mac, and Android implementations. There are some issues with some implementations (iOS will create an entirely new MAC address if it has not connected to the named WIFI in some number of weeks, which can require all new device registrations for users). In any case, changing defaults that can impact user experience (or are required to be turned off, as some organizations document one needs to do for their use cases) should come with an additional toggle in the appropriate network configuration GUI menu. None of the examples of existing implementations for popular consumer platforms requires one to go into the terminal window and directly manipulate files. They all have a GUI toggle. Apple has their toggle called "Private Addresses"; Windows has their toggle called "Random Hardware Address"; Android has their toggle called "Privacy/Use Device MAC address" (at least that is what I think the names are, I don't actually have all of those platforms to test). It would be my recommendation that the various network configuration GUIs that are part of an official Fedora edition MUST have a GUI toggle to turn off MAC address randomization (I would guess under the Security tab?), and such a toggle SHOULD be included for all official spins. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F40 Change Proposal: Wifi MAC Randomization (System Wide)
I would like to avoid duplicates and unnecessary redundancy, but especially for the issue discussed below it might be worth to also review the discussion on discussion.fp.org -> I am not convinced if it is that easy for all users when it comes to existing network configurations / setups, especially for users without sophisticated knowledge of the technical background -> https://discussion.fedoraproject.org/t/f40-change-proposal-wifi-mac-randomization-system-wide/99856 Btw, does anyone know if this (in the practically-same manner) is really already introduced in Windows, Mac, Android by default? Globally? This question indirectly came up in the discussion.fp.org topic and might impact how far vendors of routers and comparable devices/systems/software already consider MAC randomization (in existing networks / network configurations and such) to avoid issues for average users. Best, Chris On 21/12/2023 14.53, Neal Gompa wrote: On Thu, Dec 21, 2023 at 8:52 AM Leigh Scott wrote: I'm -1 for this change, it shouldn't be enabled by default as it will cause issues for users using router mac filtering. What this seems to state is that the MAC address would be unique for each SSID, but once it's picked, it would be locked in. That should still make router-level MAC filtering possible, since the MAC address would be stable for that network. -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F40 Change Proposal: Wifi MAC Randomization (System Wide)
Hi,
On Thu, 2023-12-21 at 16:08 +, Gary Buhrmaster wrote:
> On Thu, Dec 21, 2023 at 2:49 PM Tom Hughes via devel
> wrote:
> >
> > On 21/12/2023 14:33, Steven A. Falco wrote:
> > > On 12/21/23 08:53 AM, Neal Gompa wrote:
> > > > On Thu, Dec 21, 2023 at 8:52 AM Leigh Scott
> > > >
> > > > wrote:
> > > > >
> > > > > I'm -1 for this change, it shouldn't be enabled by default as
> > > > > it will
> > > > > cause issues for users using router mac filtering.
If you configure the devices MAC addresses on your router, you have a
somewhat established procedure how to do that. E.g. when a family
member gets a new notebook.
The upgrade to Fedora 40, will be a one time event, where you have to
do that again (or you opt out from the change).
> > > >
> > > > What this seems to state is that the MAC address would be
> > > > unique for
> > > > each SSID, but once it's picked, it would be locked in. That
> > > > should
> > > > still make router-level MAC filtering possible, since the MAC
> > > > address
> > > > would be stable for that network.
> > >
> > > What would happen on a network where I've set up the DHCP server
> > > in my
> > > router to map mac addresses to static IP addresses? Sounds like
> > > I'd
> > > have to disable the feature, at least on my home network.
> >
> > Either that or you would make a one off change to your DHCP server
> > to use the new per-network MAC address instead of the old one.
>
> Would it not have to be done every time
> one reinstalls their system?
Yes. Unless you copy over /etc/machine-id and
/var/lib/NetworkManager/secret_key.
These 2 files are the identity of your machine. If you lose them during
re-install, you get a different machine. The same already applies with
`ipv6.addr-gen-mode`, which defaults to "stable-privacy" to get RFC7217
IPv6 interface identifiers (meaning, you'll get a different IPv6
address after reinstall).
> And on
> each SSID one connects to (so connect
> to your HOME-5G (for your 5GHz AP),
> and HOME-2.4G (for your 2.4GHz AP),
> wifi networks would get different MAC
> addresses as the SSID is different?)
for the two profiles of your home network, you most likely would do
for PROFILE in HOME-5G HOME-2.4G ; do
nmcli connection modify "$PROFILE" \
connection.stable-id "my-home-wifi" \
wifi.cloned-mac-address stable
done
(or `wifi.cloned-mac-address permanent`).
With Wi-Fi we commonly have many profiles (Hotels, public Wi-Fis). Only
a small number are our home networks, where we might care about the MAC
address. You can select the best behavior for those selected few
profiles, but getting a more reasonable default ("stable-ssid") for all
other profiles.
To be clear, I also use "stable" MAC at home. For most cases, there is
little reason to use the MAC address of their hardware. Yes, I somewhat
care that for the most time I get the same IP address from my DHCP
server. If that IP address changes once after upgrade to Fedora 40, I
don't care. And it's not even said, that the IP address is going to
change. NetworkManager has the DHCP lease stored on disk, it will ask
the server to hand out the same IP address.
>
> (side note: some DHCP servers may
> not like assigning different MACs to
> the same IP address to allow individuals
> to choose their own access point
> frequency range based SSID).
>
> While doing so as an individual would
> probably be minorly annoying, for some
> orgs, "re-imaging" a system is the
> standard practice for repair (or
> redeployment, or for each reboot
> for guest systems) and having a stable
> MAC address (whether wired or wireless)
> is necessary for institutional requirements.
Would a company network really care about the MAC address? It doesn't
seem to scale, that new devices need to be registered.
Seems such an org is also pre-deploying configuration on the machine.
The profiles can be pre-deployed with "wifi.cloned-mac-address
permanent".
Or just a
$ touch /etc/NetworkManager/conf.d/22-wifi-mac-addr.conf
to disable all what this change brings.
>
> And for some orgs with advanced 802.1x
> network access controls, changing MAC
> addresses may result in even more
> additional tasks across different parts
> of the organization (yes, one should not
> use mac authentication alone for
> 802.1x, but that is a different topic).
>
> For orgs with a more sophisticated
> process, updating their ansible
> provisioning scripts to change the
> NetworkManager to use the hardware
> address may be possible, although for
> others, that will be one more step for
> tech support to have to do manually
> (and, of course, occasionally forget to
> do, as they are always overworked),
If you company tech support expects a call if the MAC address of the
users notebook changes, they can also expect a call when they use a
different notebook. That is asking for work.
> but
> at the very least the proposal should
> probably call out that change
> requirement more explicitly for such
>
Re: F40 Change Proposal: Wifi MAC Randomization (System Wide)
On Thu, Dec 21, 2023 at 2:49 PM Tom Hughes via devel wrote: > > On 21/12/2023 14:33, Steven A. Falco wrote: > > On 12/21/23 08:53 AM, Neal Gompa wrote: > >> On Thu, Dec 21, 2023 at 8:52 AM Leigh Scott > >> wrote: > >>> > >>> I'm -1 for this change, it shouldn't be enabled by default as it will > >>> cause issues for users using router mac filtering. > >> > >> What this seems to state is that the MAC address would be unique for > >> each SSID, but once it's picked, it would be locked in. That should > >> still make router-level MAC filtering possible, since the MAC address > >> would be stable for that network. > > > > What would happen on a network where I've set up the DHCP server in my > > router to map mac addresses to static IP addresses? Sounds like I'd > > have to disable the feature, at least on my home network. > > Either that or you would make a one off change to your DHCP server > to use the new per-network MAC address instead of the old one. Would it not have to be done every time one reinstalls their system? And on each SSID one connects to (so connect to your HOME-5G (for your 5GHz AP), and HOME-2.4G (for your 2.4GHz AP), wifi networks would get different MAC addresses as the SSID is different?) (side note: some DHCP servers may not like assigning different MACs to the same IP address to allow individuals to choose their own access point frequency range based SSID). While doing so as an individual would probably be minorly annoying, for some orgs, "re-imaging" a system is the standard practice for repair (or redeployment, or for each reboot for guest systems) and having a stable MAC address (whether wired or wireless) is necessary for institutional requirements. And for some orgs with advanced 802.1x network access controls, changing MAC addresses may result in even more additional tasks across different parts of the organization (yes, one should not use mac authentication alone for 802.1x, but that is a different topic). For orgs with a more sophisticated process, updating their ansible provisioning scripts to change the NetworkManager to use the hardware address may be possible, although for others, that will be one more step for tech support to have to do manually (and, of course, occasionally forget to do, as they are always overworked), but at the very least the proposal should probably call out that change requirement more explicitly for such orgs. Given the unknown impact on larger organization customers (rather than individuals taking their own devices to an overpriced coffee shop), I am currently leaning on the -1 side. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F40 Change Proposal: Wifi MAC Randomization (System Wide)
On 21/12/2023 14:33, Steven A. Falco wrote: On 12/21/23 08:53 AM, Neal Gompa wrote: On Thu, Dec 21, 2023 at 8:52 AM Leigh Scott wrote: I'm -1 for this change, it shouldn't be enabled by default as it will cause issues for users using router mac filtering. What this seems to state is that the MAC address would be unique for each SSID, but once it's picked, it would be locked in. That should still make router-level MAC filtering possible, since the MAC address would be stable for that network. What would happen on a network where I've set up the DHCP server in my router to map mac addresses to static IP addresses? Sounds like I'd have to disable the feature, at least on my home network. Either that or you would make a one off change to your DHCP server to use the new per-network MAC address instead of the old one. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F40 Change Proposal: Wifi MAC Randomization (System Wide)
On 12/21/23 08:53 AM, Neal Gompa wrote: On Thu, Dec 21, 2023 at 8:52 AM Leigh Scott wrote: I'm -1 for this change, it shouldn't be enabled by default as it will cause issues for users using router mac filtering. What this seems to state is that the MAC address would be unique for each SSID, but once it's picked, it would be locked in. That should still make router-level MAC filtering possible, since the MAC address would be stable for that network. What would happen on a network where I've set up the DHCP server in my router to map mac addresses to static IP addresses? Sounds like I'd have to disable the feature, at least on my home network. Steve -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F40 Change Proposal: Wifi MAC Randomization (System Wide)
On Thu, Dec 21, 2023 at 8:52 AM Leigh Scott wrote: > > I'm -1 for this change, it shouldn't be enabled by default as it will cause > issues for users using router mac filtering. What this seems to state is that the MAC address would be unique for each SSID, but once it's picked, it would be locked in. That should still make router-level MAC filtering possible, since the MAC address would be stable for that network. -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F40 Change Proposal: Wifi MAC Randomization (System Wide)
I'm -1 for this change, it shouldn't be enabled by default as it will cause issues for users using router mac filtering. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F40 Change Proposal: Wifi MAC Randomization (System Wide)
Wiki -> https://fedoraproject.org/wiki/Changes/WifiMACRandomization This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == Adopt stable-ssid as the default MAC address randomization mode for Wi-Fi networks in NetworkManager for Fedora 40, enhancing user privacy without compromising network stability. == Owner == * Name: [[User:sfaye| Stanislas FAYE]], [[User:Till| Till Maas]] * Email: , == Detailed Description == The change involves adding a new file, /usr/lib/NetworkManager/conf.d/22-wifi-mac-addr.conf. This file sets `wifi.cloned-mac-address=”stable-ssid”` as the default mode for MAC address randomization in Wi-Fi connections within NetworkManager for [https://docs.fedoraproject.org/en-US/releases/f40/ Fedora Linux 40]. The `stable-ssid` mode, which generates a MAC address based on the network's SSID, is aimed at enhancing user privacy. This new default value will apply to Wi-Fi profiles in [https://docs.fedoraproject.org/en-US/releases/f40/ Fedora Linux 40], but profiles have the option to explicitly set different values to override the default. The content of the added file is: [connection.22-wifi-mac-addr] match-device=type:wifi wifi.cloned-mac-address=stable-ssid [.config] enable=nm-version-min:1.45 For further details, please refer to `man NetworkManager.conf`. Note that this change will impact networks that rely on static MAC addresses. Users may need to adjust their Wi-Fi settings, particularly if their network operations depend on consistent MAC addresses. For example, networks with access control based on MAC addresses will need to explicitly set `wifi.cloned-mac-address` to “preserve” in network profiles to avoid any disruptions in connectivity. == Benefit to Fedora == This change enhances user privacy by addressing the issue of MAC address tracking method used by network operators and advertisers to gather data about users’ movements and device usage patterns. By randomizing MAC addresses, Fedora reduces the potential for this type of passive surveillance, thereby enhancing individual privacy. It aligns Fedora with privacy-focused features present in other modern operating systems. The generated MAC address under the `stable-ssid` mode is derived from the network’s SSID, a per-host key (from `/etc/machine-id` and `/var/lib/NetworkManager/secret_key`), and a per-interface identifier. == Scope == * Proposal owners: The [https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1789 merge request] is already merged upstream. * Other developers: N/A * Release engineering: [https://pagure.io/releng/issues #Releng issue number] * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == With the adoption of `stable-ssid` as the default in Fedora 40, existing users may experience changes in their Wi-Fi connection behavior, particularly those whose network setups depend on fixed MAC addresses. It’s crucial for users to be aware that upgrading to Fedora 40 will apply this new MAC address randomization by default. Users needing to maintain consistent MAC addresses for specific networks can address this by following one of these steps: 1. Manually set `wifi.cloned-mac-address` to `permanent` for specific profiles using `nmcli connection modify [$PROFILE] wifi.cloned-mac-address permanent` 2. Create a custom configuration file in `/etc/NetworkManager/conf.d/22-wifi-mac-addr.conf`, which can be empty or contain specific configurations. This will prevent the default file in `/usr/lib` from being loaded. 3. Create a higher priority .conf file like /etc/NetworkManager/conf.d/90-wifi-mac-addr.conf with: [connection-90-wifi-mac-addr-conf] wifi.cloned-mac-address=permanent For details on the order in which configuration files are loaded and their priority, refer to `man NetworkManager.conf` == How To Test == * Upgrade NetworkManager to version 1.45 or newer implementing the stable-ssid mode * Connect to Wi-Fi network using nmcli or the GNOME network settings * Use `ip link show` (replacing [device] with your Wi-Fi device’s name) to check the MAC address assigned to the device. * Note the MAC address and reconnect to the same network to confirm that the MAC address remains consistent across sessions. * Connect to different Wi-Fi networks and observe the MAC address for each connection. * Ensure that the MAC address is derived from the network’s SSID. * Manually override the MAC address for a specific Wi-Fi profile using `nmcli connection modify [profile] wifi.cloned-mac-address [your-mac-address]` to set a specific MAC address * Reconnect to the network and use `nmcli device show [device]` to verify that the specified MAC address is being used. ==
F40 Change Proposal: Wifi MAC Randomization (System Wide)
Wiki -> https://fedoraproject.org/wiki/Changes/WifiMACRandomization This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == Adopt stable-ssid as the default MAC address randomization mode for Wi-Fi networks in NetworkManager for Fedora 40, enhancing user privacy without compromising network stability. == Owner == * Name: [[User:sfaye| Stanislas FAYE]], [[User:Till| Till Maas]] * Email: , == Detailed Description == The change involves adding a new file, /usr/lib/NetworkManager/conf.d/22-wifi-mac-addr.conf. This file sets `wifi.cloned-mac-address=”stable-ssid”` as the default mode for MAC address randomization in Wi-Fi connections within NetworkManager for [https://docs.fedoraproject.org/en-US/releases/f40/ Fedora Linux 40]. The `stable-ssid` mode, which generates a MAC address based on the network's SSID, is aimed at enhancing user privacy. This new default value will apply to Wi-Fi profiles in [https://docs.fedoraproject.org/en-US/releases/f40/ Fedora Linux 40], but profiles have the option to explicitly set different values to override the default. The content of the added file is: [connection.22-wifi-mac-addr] match-device=type:wifi wifi.cloned-mac-address=stable-ssid [.config] enable=nm-version-min:1.45 For further details, please refer to `man NetworkManager.conf`. Note that this change will impact networks that rely on static MAC addresses. Users may need to adjust their Wi-Fi settings, particularly if their network operations depend on consistent MAC addresses. For example, networks with access control based on MAC addresses will need to explicitly set `wifi.cloned-mac-address` to “preserve” in network profiles to avoid any disruptions in connectivity. == Benefit to Fedora == This change enhances user privacy by addressing the issue of MAC address tracking method used by network operators and advertisers to gather data about users’ movements and device usage patterns. By randomizing MAC addresses, Fedora reduces the potential for this type of passive surveillance, thereby enhancing individual privacy. It aligns Fedora with privacy-focused features present in other modern operating systems. The generated MAC address under the `stable-ssid` mode is derived from the network’s SSID, a per-host key (from `/etc/machine-id` and `/var/lib/NetworkManager/secret_key`), and a per-interface identifier. == Scope == * Proposal owners: The [https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1789 merge request] is already merged upstream. * Other developers: N/A * Release engineering: [https://pagure.io/releng/issues #Releng issue number] * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == With the adoption of `stable-ssid` as the default in Fedora 40, existing users may experience changes in their Wi-Fi connection behavior, particularly those whose network setups depend on fixed MAC addresses. It’s crucial for users to be aware that upgrading to Fedora 40 will apply this new MAC address randomization by default. Users needing to maintain consistent MAC addresses for specific networks can address this by following one of these steps: 1. Manually set `wifi.cloned-mac-address` to `permanent` for specific profiles using `nmcli connection modify [$PROFILE] wifi.cloned-mac-address permanent` 2. Create a custom configuration file in `/etc/NetworkManager/conf.d/22-wifi-mac-addr.conf`, which can be empty or contain specific configurations. This will prevent the default file in `/usr/lib` from being loaded. 3. Create a higher priority .conf file like /etc/NetworkManager/conf.d/90-wifi-mac-addr.conf with: [connection-90-wifi-mac-addr-conf] wifi.cloned-mac-address=permanent For details on the order in which configuration files are loaded and their priority, refer to `man NetworkManager.conf` == How To Test == * Upgrade NetworkManager to version 1.45 or newer implementing the stable-ssid mode * Connect to Wi-Fi network using nmcli or the GNOME network settings * Use `ip link show` (replacing [device] with your Wi-Fi device’s name) to check the MAC address assigned to the device. * Note the MAC address and reconnect to the same network to confirm that the MAC address remains consistent across sessions. * Connect to different Wi-Fi networks and observe the MAC address for each connection. * Ensure that the MAC address is derived from the network’s SSID. * Manually override the MAC address for a specific Wi-Fi profile using `nmcli connection modify [profile] wifi.cloned-mac-address [your-mac-address]` to set a specific MAC address * Reconnect to the network and use `nmcli device show [device]` to verify that the specified MAC address is being used. ==
