Rintel: NetworkManager 1.4: with better privacy and easier to use
It is now possible to randomize the MAC address of Ethernet devices to mitigate possibility of tracking. The users can choose between different policies; use a completely random address, or just use different addresses in different networks. For Wi-Fi devices, the same randomization modes are now supported and does no longer require support from wpa-supplicant." Also a newly added API for using configuration snapshots that automatically roll back after a timeout, IPv6 tokenized interface identifiers can be configured, new features in nmcli, and more are covered. (Thanks to Paul Wise)
Posted Aug 25, 2016 20:49 UTC (Thu)
by zlynx (guest, #2285)
[Link] (9 responses)
Posted Aug 25, 2016 23:16 UTC (Thu)
by pr1268 (guest, #24648)
[Link] (3 responses)
I dunno... Seems like someone latching on to a coffee shop's WiFi and then visiting e.g. Facebook, Yahoo! Mail/Gmail/Outlook.com, some newspaper or online news site, and then likely a banking site, would generate a cookie-cutter John Q. Normal visited-site profile. That one user that logs into BillyBob's™ WiFi at precisely 2:00 PM daily and visits cuteoverload.com is probably not too concerned about randomizing their MAC address. ;-) Browser fingerprinting could be a more effective specific user identifier. Not that I disagree with you, though. Doesn't anyone suppose whoever uses the MAC address randomization would also be paranoid enough to go the Tor route?
Posted Aug 26, 2016 2:57 UTC (Fri)
by pabs (subscriber, #43278)
[Link] (2 responses)
Posted Aug 26, 2016 3:42 UTC (Fri)
by zlynx (guest, #2285)
[Link] (1 responses)
Posted Aug 26, 2016 9:22 UTC (Fri)
by Lennie (subscriber, #49641)
[Link]
https://trac.torproject.org/projects/tor/wiki/doc/meek#Ov...
Posted Aug 26, 2016 8:09 UTC (Fri)
by grawity (subscriber, #80596)
[Link] (2 responses)
That said, I'd much rather networks started getting rid of the spawn of evil called "captive portal"...
Posted Aug 27, 2016 0:53 UTC (Sat)
by lsl (subscriber, #86508)
[Link] (1 responses)
Yes, please. Sadly, it seems that no one is willing to kill them off, many even going as far as poking holes into their DNSSEC implementations so the horrors can continue to haunt us.
Posted Aug 27, 2016 3:45 UTC (Sat)
by raven667 (subscriber, #5198)
[Link]
Posted Aug 26, 2016 12:59 UTC (Fri)
by Felix (guest, #36445)
[Link]
I think the "attack scenario" is more Google Analytics-style tracking: There are (were?) quite a few companies who sold hardware to store owners to "learn more" about their customers/passing people based on their MAC address.
e.g.
So randomizing the MAC address when scanning for networks just completely destroys that tracking.
Posted Aug 31, 2016 12:32 UTC (Wed)
by paulj (subscriber, #341)
[Link]
Posted Aug 27, 2016 12:44 UTC (Sat)
by barryascott (subscriber, #80640)
[Link] (7 responses)
Posted Aug 27, 2016 21:03 UTC (Sat)
by gerdesj (subscriber, #5446)
[Link] (6 responses)
It only needs to be unique within a collision domain. This is Layer 2 only and doesn't have to be globally unique.
On a /24 network there might be say 250 unique MAC addresses. Assuming that they are randomly distributed in the possible address space, then your chance of picking a duplicate is 200/(2^48) or 7.11^-13. That's in the region of "1 in 70 billion".
If you can reliably get a collision, would you mind selecting my lottery numbers please?
Posted Aug 28, 2016 3:57 UTC (Sun)
by smckay (guest, #103253)
[Link] (5 responses)
Posted Aug 30, 2016 15:46 UTC (Tue)
by nye (subscriber, #51576)
[Link] (4 responses)
Yes, if you have the entire population of Delhi in your coffee shop at once, all attempting to connect to the same access point, this would indeed be a problem. All things considered though, I suspect in this situation you probably have bigger problems.
Posted Sep 5, 2016 14:27 UTC (Mon)
by robbe (guest, #16131)
[Link] (3 responses)
With WiFi this is out of the question … but I can imagine some big datacenters, or stretched LANs, or whatever using something monstrous like that. Of course, the overhead would be painful. Even if you *only* broadcast for ARP, and each node only does one resolution per minute, your sustained broadcast traffic is 106 Mbit.
Posted Sep 5, 2016 14:57 UTC (Mon)
by farnz (subscriber, #17727)
[Link]
Note that WiFi in its rawest form just bridges between a wired 802.3 network and the RF domain. Thus, if you can build such an insane broadcast domain with wired networks, you can build it with lots of APs all bridging onto that wired network.
So, even on WiFi, you can end up with such a crazy domain; modern APs support ARP proxy behaviour, where they maintain a cache of ARP replies from the WiFi side (invalidated when the WiFi station that sent the reply disassociates), so that the 106 Mbit/s of ARP traffic doesn't hit the RF network.
Posted Sep 5, 2016 18:34 UTC (Mon)
by tialaramex (subscriber, #21167)
[Link] (1 responses)
With IPv6 you can use multicast neighbour discovery, where you figure out an Ethernet multicast address that the node you're looking for must be listening on, and send the discovery request to that address. Switches can cache the members of the multicast groups reachable across all the links they can see. A cheap switch such as the little Netgears often found in the "computer networks" section of an office supply store will probably lose its mind faced with tens of millions of nodes, but big beefy Cisco datacentre switches might just chew lots of RAM making this work. I mean, it will undoubtedly explode for _some_ reason, but whatever breaks might be optional, and if it isn't a Cisco tech might be able to fix it (charge your tens of millions of users a dollar each and you can afford Cisco's ridiculous support contract prices) so that you can get your 13M node network to come up and stay up without every link choking on 100+ Mbps of idle chatter.
Even if you can't do anything in the switches, using multicast rather than ARP's all-addresses broadcast saves you going up to the OS network code to determine that nope, this ARP request isn't for me and I should ignore it. A cheap built-in Ethernet implementation can handle 100Mbps of non-matching multicast traffic without waking the OS.
Posted Sep 6, 2016 6:25 UTC (Tue)
by farnz (subscriber, #17727)
[Link]
Note that good APs can do NDP proxying too, so NDP traffic doesn't go on the RF segment either.
Posted Aug 27, 2016 17:17 UTC (Sat)
by simlo (guest, #10866)
[Link] (16 responses)
Posted Aug 27, 2016 23:13 UTC (Sat)
by HenrikH (subscriber, #31152)
[Link] (15 responses)
Posted Aug 28, 2016 7:37 UTC (Sun)
by anselm (subscriber, #2796)
[Link] (2 responses)
And of course it is perfectly possible to use the normal NetworkManager on a systemd-based system instead of systemd-networkd.
Systemd-networkd is a much simpler program than NetworkManager and does not attempt to compete with it; it is supposed to cover the straightforward cases, like that of a workstation within a wired network whose networking setup seldom if ever changes, without the complexity that NetworkManager adds to be able to deal with the less straightforward ones.
Posted Aug 28, 2016 8:28 UTC (Sun)
by Cyberax (✭ supporter ✭, #52523)
[Link] (1 responses)
For desktop systems connecting to WiFi or cellular networks and then doing complicated VPNs? Not so much.
Posted Aug 28, 2016 23:39 UTC (Sun)
by flussence (guest, #85566)
[Link]
Posted Aug 28, 2016 19:46 UTC (Sun)
by fishface60 (subscriber, #88700)
[Link] (11 responses)
Posted Aug 29, 2016 16:47 UTC (Mon)
by SEJeff (guest, #51588)
[Link] (10 responses)
Posted Aug 29, 2016 20:46 UTC (Mon)
by johannbg (guest, #65743)
[Link] (9 responses)
If networkd gains (d)bus interface you can kiss NM good buy since you dont need it on your embedded/servers/containers/vm or desktop. In fact you don't need it today on any of these openconnect,wpa_supplicant ( if using Fedora use the upstream wpa supplicant type unit, the Fedora shipped one has been violated by NM-ism ) etc all work quite well with networkd.
Posted Aug 29, 2016 21:25 UTC (Mon)
by pizza (subscriber, #46)
[Link] (8 responses)
Oh? What about this (directly lifted from Fedora 24) has anything to do with NetworkManager?
[Unit]
[Service]
[Install]
...That's it.
(And '/etc/sysconfig/wpa_supplicant' by default just adds '-s' to OTHER_ARGS, ie log to syslog)
Now the contents of /etc/wpa_supplicant/wpa_supplicant.conf is intended to be used by NetworkManager (it only includes settings specifying the control socket) but one can just change that to their heart's content, disable/remove NetworkManager, and get on with life.
Posted Aug 29, 2016 21:42 UTC (Mon)
by johannbg (guest, #65743)
[Link] (7 responses)
You will need to implement the non dbus shipped upstream type unit file to be able to "get on with life" once you remove NM in the distribution.
Next time I suggest you try what you preach before blurbing it here on lwn.
Posted Aug 29, 2016 22:11 UTC (Mon)
by pizza (subscriber, #46)
[Link] (5 responses)
Then you would have communicated something useful to the discussion, instead of another helping of snarky bitterness.
Posted Aug 30, 2016 0:19 UTC (Tue)
by johannbg (guest, #65743)
[Link] (4 responses)
If you had then gone digging further you would have figured out that the upstream type unit file to support what you indicated should work was nowhere to be found in the wpa_supplicant package shipped in Fedora, despite the fact the both upstream unit ( the device type and dbus type ) can be co-installed and co-exist in distributions and realized that end users steps are not as simple as stop/disabled wpa supplicant type dbus unit, removing NM and starting/enabling the wpa supplicant device type unit.
Then you would have most likely wondered why that is and looked at who maintain wpa_supplicant in Fedora and at that moment had your Eureka in which you realized what I was referring to when I said "Fedora shipped one has been violated by NM-ism" since the wpa_supplicant package maintainers just so happen to be the one and the same as the NM ones. Those individuals made an choice of not shipping the type device wpa_supplicant unit and that choice was not based on it was not technically possible to do so or somehow would break existing installed systems if they did...
If networkd had (d)bus interface, your suggested approach might have worked as well as gnome shell extension to use it could have been written ( Gnome default network management is NM only afaik ) etc but bus support in networkd is taking longer time than I had personally expected which may be because of kdbus/bus1 and or some "political" reasons or the classic lack of time.
Posted Aug 30, 2016 2:29 UTC (Tue)
by pizza (subscriber, #46)
[Link] (3 responses)
The unit file that Fedora ships is nearly identical to one of the four sample systemd unit files that upstream wpa_supplicant supplies. It's the configuration that Fedora chooses to integrate and support, and is just one of many choices made by the Fedora packagers and maintainers in putting together a coherent distribution.
Meanwhile. Of the 175 total tickets (open and closed) on RHBZ that reference 'wpa_supplicant' and 'systemd', and 104 tickets that reference 'wpa_supplicant' and 'unit', there does not appear to be a request/complaint about not having a non-dbus-based unit file, much less a WONT rejection.
So yes, saying that they don't ship a non-dbus unit file is a reasonable complaint, but ascribing that to willful malice and/or incompetence on Fedora's part when nobody seems to have so much as asked for that feature is going a bit too far, especially when there are reasonable arguments for Fedora's maintainers making the choice they did.
Oh, one more thing -- Don't presume to tell me what I would have most likely [not] done and what my motivations were [not]. You were quite wrong, and proceeded to project your anti-RH biases onto me. (Again). It does you, and your arguments, no service.
Posted Aug 30, 2016 8:00 UTC (Tue)
by johannbg (guest, #65743)
[Link] (2 responses)
Posted Aug 30, 2016 12:14 UTC (Tue)
by pizza (subscriber, #46)
[Link] (1 responses)
Meanwhile, a good technical argument for not including the non-dbus unit file is that it simply wouldn't work out of the box; in other words you'd have to edit either a secondary configuration file (such as the "useless" EnvironmentFile that would be invaluable in this instance -- ie cleanly separating the two different invocation mechanisms -- Maybe you should take your own advice and think about what you write?) or the unit file itself in order for the supplicant to do anything useful. Following from that, it'll lead to support problems whith people enable/disable the wrong unit or configuration file. (As someone who has had to perform that sort of support, it's far from a theoretical concern). Similarly, blindly launching the supplicant in of itself won't give you a working network connection, it has to interact with things like a DHCP client and the rest of the system network configuration. A nontrivial amount of customization is necessary to make that actually work.
Granted, perhaps the supplicant package maintainers could have provided the other three systemd unit files as examples under /usr/share/doc, but I suspect folks able to manually configure wpa_supplicant (and deal with the interactions with the rest of the networking subsystem) are sufficiently clued to figure out how to blindly launch it via systemd if they so choose.
Personally, I didn't take that approach with the one system of mine that has to work that way; I created a separate "start wifi networking" shell script that manually invokes iw, the supplicant, and ifconfig/dhcp/etc, and is launched via a trivial systemd service unit. I should probably revisit it, when set up the box was running F19 and there's probably a better, more integrated way of going about it now.
Anyway. Since you never filed a patch, and nobody else apparently cares sufficiently about this use case, it's hardly surprising that the integrated supplicant unit file is stuck in a "good enough for the use cases we are targeting" state.
As for blaming "my coworkers" for the distribution being "off track" -- I'll repeat myself by stating that have never worked for RedHat, or contributed to Fedora beyond very occasional bug reports and patches. Since you're apparently not participating beyond making snide remarks on unrelated forums, it's not surprising that your views on what is "right" aren't being given any consideration, much less being acted on.
Generally speaking, going into a discussion with an voliminously-expressed hostile chip on your shoulder and accusing those you're trying to influence of Machevellian malice and/or incompetence doesn't exactly encourage them to work with you. As the saying goes, You can attract more flies with honey than vinegar.
Posted Aug 30, 2016 19:21 UTC (Tue)
by johannbg (guest, #65743)
[Link]
Posted Sep 3, 2016 12:03 UTC (Sat)
by mathstuf (subscriber, #69389)
[Link]
Posted Aug 30, 2016 20:12 UTC (Tue)
by dkg (subscriber, #55359)
[Link]
This is troubling because network-manager isn't the only tool that's capable of randomizing the mac address. on modern systems, udev itself is capable of doing so (see "MacAddressPolicy=random" in systemd.link(5). So it's possible to set a randomized hardware address via the userspace tool that actually first touches the device; but if network-manager then picks it up and hasn't been explicitly configured away from its default, network-manager will actually override the lower-layer randomization.
Even worse, the default for network-manager used to be preserve, but it got changed accidentally to permanent. So if you want a device to be randomized by userspace at the earliest possible point, you now have to change two settings on a typical GNU/Linux system (one with both udev and NetworkManager) -- you have to set up a .link file and you have to tell n-m to leave the MAC address alone.
It'd be great for n-m to switch the default back to preserve. I welcome comments on the upstream bug about that.
Rintel: NetworkManager 1.4: with better privacy and easier to use
Rintel: NetworkManager 1.4: with better privacy and easier to use
Rintel: NetworkManager 1.4: with better privacy and easier to use
Rintel: NetworkManager 1.4: with better privacy and easier to use
Rintel: NetworkManager 1.4: with better privacy and easier to use
The list of sites still varies over time, plus it's only visible to the network itself. The MAC address is static and visible over Wi-Fi to nearly everyone. (Less of a problem with Ethernet, but the option still might be of use.) Just because randomizing it won't close all the holes, doesn't mean it's stupid to start closing them one by one.
Rintel: NetworkManager 1.4: with better privacy and easier to use
Rintel: NetworkManager 1.4: with better privacy and easier to use
Rintel: NetworkManager 1.4: with better privacy and easier to use
Rintel: NetworkManager 1.4: with better privacy and easier to use
- "was that MAC address seen before?"
- "how many people passed by vs. entered the shop?"
- "which way did they walk in the shop?"
and in the demo I got they were even able to connect sales to the previously recorded track data pretty well.
Rintel: NetworkManager 1.4: with better privacy and easier to use
Rintel: NetworkManager 1.4: with better privacy and easier to use
Rintel: NetworkManager 1.4: with better privacy and easier to use
Rintel: NetworkManager 1.4: with better privacy and easier to use
Rintel: NetworkManager 1.4: with better privacy and easier to use
Rintel: NetworkManager 1.4: with better privacy and easier to use
Rintel: NetworkManager 1.4: with better privacy and easier to use
IPv6 ?
IPv6 ?
Rintel: NetworkManager 1.4: with better privacy and easier to use
Rintel: NetworkManager 1.4: with better privacy and easier to use
Rintel: NetworkManager 1.4: with better privacy and easier to use
Rintel: NetworkManager 1.4: with better privacy and easier to use
Rintel: NetworkManager 1.4: with better privacy and easier to use
On those systems I'd recommend connman, very enthusiastically. It's also the only thing I've ever seen that's convinced the horror known as BlueZ to *work* for longer than 5 seconds, without pulling in an entire desktop environment as dependencies.
Rintel: NetworkManager 1.4: with better privacy and easier to use
Rintel: NetworkManager 1.4: with better privacy and easier to use
Rintel: NetworkManager 1.4: with better privacy and easier to use
Let's just say there has been more collaboration between existing NM rival project and networkd than there has been between NM and networkd and leave it at that ;)
Rintel: NetworkManager 1.4: with better privacy and easier to use
Description=WPA supplicant
Before=network.target
Wants=network.target
After=dbus.service
Type=dbus
BusName=fi.w1.wpa_supplicant1
EnvironmentFile=-/etc/sysconfig/wpa_supplicant
ExecStart=/usr/sbin/wpa_supplicant -c /etc/wpa_supplicant/wpa_supplicant.conf -u $INTERFACES $DRIVERS $OTHER_ARGS
WantedBy=multi-user.target
Rintel: NetworkManager 1.4: with better privacy and easier to use
Rintel: NetworkManager 1.4: with better privacy and easier to use
Rintel: NetworkManager 1.4: with better privacy and easier to use
Rintel: NetworkManager 1.4: with better privacy and easier to use
Rintel: NetworkManager 1.4: with better privacy and easier to use
Rintel: NetworkManager 1.4: with better privacy and easier to use
Rintel: NetworkManager 1.4: with better privacy and easier to use
Rintel: NetworkManager 1.4: with better privacy and easier to use
I'm happy to see these fixes with network manager! however, i don't like that network manager defaults the setting of ethernet.cloned-mac-address as "permanent", rather than "preserve" (see discussion on gnome bz #708820). "permanent" means "reset this device to its burned in address", while "preserve" means "leave it how you found it."
Rintel: NetworkManager 1.4: with better privacy and easier to use