Bug #7165
NetworkManager autoconnects to persistent wireless networks
100%
Description
This was not the case in Squeeze; all persistent wireless networks in range were only listed, not auto connected to. The “Connect automatically” option wasn’t saved properly, making it always act as if disabled (well, only after rebooting Tails, not during the session it was added). While this actually is a bug, this behaviour is desirable (except the discrepancy with rebooting). We wanted to consider it a feature but ended up calling it a known issue. Now we may want to revisit this.
Do we want to always disable “Connect automatically” and remove the check box (by patching `nm-applet`) or similar, and if so, is it blocking Tails 1.1? In any case the known issue should be removed.
Subtasks
| Feature #7622: Check if NetworkManager allows disabling the autoconnect parameter by default | Resolved | 0 |
Related issues
|
Related to Tails - |
Resolved | 2014-05-11 | |
|
Related to Tails - |
Resolved | 2014-09-19 |
History
#1 Updated by intrigeri 2014-05-06 16:38:03
> We wanted to consider it a feature but ended up calling it a known
> issue.
> Now we may want to revisit this.
Especially now that we have MAC spoofing enabled by default, I’m in
favour with keeping the status quo in terms of analysis, that is to
call it a known issue in Squeeze, that is resolved in Wheezy.
So, I would advise to remove the known issue in the devel branch,
and to mark this ticket as “Fix committed”.
Nice catch, anyway!
#2 Updated by anonym 2014-05-08 20:26:08
- Target version deleted (
Tails_1.1)
For now we’ve decided it’s not a 1.1 blocker.
#3 Updated by intrigeri 2014-06-11 12:40:26
201405 meeting notes:
- A proposal was to do nothing, and remove the 3 lines about that from the Known issues.
- But that makes it harder to work totally offline.
- MAC spoofing does nothing for the edge case where the persistent wireless network has WPA Enterprise with unique user credentials
- To work offline people can disconnect before starting any application, so the attack surface is “only” the kernel + whatever runs by default. We can probably live with that.
- We decided that was not a blocker for 1.1.
- The question remains open whether this would be a desirable behaviour to have back in Tails.
- We could have a look at the NetworkManager parameter to not autoconnect and see if it can be made “off” by default.
#4 Updated by intrigeri 2014-06-11 12:41:20
- related to
Feature #6811: Add Tails Greeter option for disabling networking added
#5 Updated by sajolida 2014-12-16 12:51:30
Someone mentioned on tails-ux that WPA with unique user credentials is not only an edge. If you consider the eduraom network (https://www.eduroam.org/). Having your Tails automatically connect and send your credentials to such a network can reveal your location pretty badly.
#6 Updated by anonym 2014-12-16 13:50:24
sajolida wrote:
> Someone mentioned on tails-ux that WPA with unique user credentials is not only an edge. If you consider the eduraom network (https://www.eduroam.org/). Having your Tails automatically connect and send your credentials to such a network can reveal your location pretty badly.
This is a very good point, and has made me pretty convinced that we really should do something about this. For the record, I’ve been personally surprised by eduroam’s presence a couple of times, e.g. at IRILL. :)
I vote for Discuss -> Code. I might take the ticket unless someone else feels like it, but I wouldn’t want to commit to any actual work until after 1.3 has been released, at least.
#7 Updated by BitingBird 2014-12-19 14:02:07
- Type of work changed from Discuss to Code
#8 Updated by sajolida 2015-04-19 09:33:26
- related to
Feature #7185: Document the interface for editing network connections added
#9 Updated by Anonymous 2018-01-18 17:11:53
- Subject changed from NetworkManager autoconnects to persistent wireless networks in Wheezy to NetworkManager autoconnects to persistent wireless networks
Is this still something that we consider modifying, even on Stretch?
#10 Updated by Anonymous 2018-08-18 13:39:50
Is this something we want to tackle ?
#11 Updated by intrigeri 2018-08-18 14:32:22
Yes, it would be good to fix this some day.
#12 Updated by geb 2020-05-12 19:34:11
- Status changed from Confirmed to In Progress
- Feature Branch set to geb:bugfix/7165-disable-NetworkManager-autoconnect-1
Lets try to close old bugs instead of opening new ones !
I gave a look to this bug :
The solution proposed on Feature #7622, while working, is not persistent. I did not manage to find a persistent one.
So far I was thinking about the following possibilities to implement something persistent or that looks persistent :
1) Patch Network Manager to allow a setting to be set for a device, similar to wifi.scan-rand-mac-address & wifi.scan-generate-mac-address-mask (ones of the few settings you can set according to man NetworkManager.conf). While it could be a nice contribution. I did not manage to estimate how difficult it could be to i) write a proper patch ii) maintain or upstream it.
2) Patch Network Manager to disable autoconnect for every connection, either in frontend (as proposed, “nm-applet”), in backend (nm-settings). This looks for me less relevant than a proper patch on NetworkManager.conf, as it may requires almost the same effort and is likely to be Tails specific (except if I miss some use cases ?).
2b) Hook Network Manager to disable autoconnect for every connection. While the hook itself is easy (for x in $(nmcli -t -f name connection); do nmcli connection modify $x connection.autoconnect no; done), I fail to see where to place it for it to be relevant & reliable.
3) Hook Network Manager to disable autoconnect on device, after it started (otherwise Feature #7622 solution(s) wont work), and before it starts to automatically connect. This looks for me more reliable than 2b) (for example, for connections that could be added), easier than 1) and 2), and also similar to the mac spoof feature that have been implemented in a simplier way, as there is no user interaction, and no hardware failure to catch.
Branch geb:bugfix/7165-disable-NetworkManager-autoconnect-1 contains a very first tentative patch to implement 3), using systemd+udev rules (for external devices that could be added after boot). Systemd service definition could benefit of being more integrated (with tails-set-wireless-devices-state.service & tails-unblock-network.service) and the script hardened (or even just allow take $interface param for udev rules). I choose to keep it as it right now for the sake of simplicity of this very first version.
I tested those patch locally on debian. I did not try to build tails with it (I dont have the resources for). Would it be possible add it to CI to see if it works as it (and if it breaks some test cases) ? Before investigating further I would like to have the opinion of UX people, as I believe it is an important change (it took me days to start to get used to), and may after all, not worth to be investigated further because of the UX drawbacks.