5 ## Using NetwokManager for AvoidConnectionProbs?
7 Instead of our current hack, we'd ideally want to hook into
8 NetworkManager's error handling, which certainly would be more robust,
9 and hopefully would provide more information about the error, but this
10 currently seems unsupported.
12 An experiment has showed that when connecting to a password-protected
13 (WPA-PSK) wireless network with MAC address white-listing, spoofed
14 (and hence blocked) MAC addresses resulted in an endless cycle of NM
15 asking for passphrase. When cancelled, NM displays a "Disconnected"
16 notification, and during this time no NM dispatcher events were
19 Some bugs of interest that may bring some hope:
21 * <https://bugzilla.gnome.org/show_bug.cgi?id=387832>
22 * <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=518368>
23 * <https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/336736>
25 ## Vendor bit randomisation with macchiato
27 These are the current relevant OUI counts from macchiato's git:
29 5 oui/bluetooth_laptop.sh
30 2 oui/bluetooth_misc.sh
31 12 oui/bluetooth_mobile.sh
32 1 oui/bluetooth_pmp.sh
33 2 oui/wired_console.sh
34 3 oui/wired_desktop_dedicated.sh
35 11 oui/wired_desktop_onboard.sh
36 8 oui/wired_infrastructure.sh
37 17 oui/wired_laptop.sh
39 4 oui/wired_printer.sh
40 2 oui/wireless_camera.sh
41 1 oui/wireless_console.sh
42 4 oui/wireless_desktop_dedicated.sh
43 2 oui/wireless_desktop_onboard.sh
44 4 oui/wireless_handheld.sh
45 6 oui/wireless_infrastructure.sh
46 1 oui/wireless_laptop_dedicated.sh
47 21 oui/wireless_laptop.sh
48 17 oui/wireless_mobile.sh
50 4 oui/wireless_printer.sh
53 In particular there's ~20 each in wireless_laptop and wired_laptop,
54 which is what we should care about most (desktops rarely need MAC
55 spoofing). However, after investigating the sources for some OUI:s
56 (via git history), some OUI:s are (according to the submitter) only
57 common in certain geographical areas. This makes the lists too small
58 and unreliable at the moment.
60 Another attempt at collecting MAC addresses for various kinds of
61 hardware is [Boruch-Baum's
62 mac_changer_choice](https://github.com/Boruch-Baum/mac_changer_choice).
64 # Questions, remaining issues, and other random stuff
66 ## MAC spoof failure warning and failsafe
68 If MAC spoofing fails for some interface we'd like to prevent it from
69 exposing the real MAC address, and warn the user about this via a
72 In the current implementation there's no failsafe that verifies that
73 the selected MAC spoofing setting has been enforced before
74 connecting. This would be easy if there was something like pre-up NM
75 dispatcher hooks but just like in the section about "Connection
76 failure detection", there's none yet.
78 An alternative would be to do this in
79 [[!tails_spoof-mac_gitweb config/chroot_local-includes/usr/local/sbin/tails-spoof-mac]], which
80 is run by the udev hook. In the end of the script we could try to
81 verify that the spoofing indeed happened for the NIC in question, and
82 if it didn't we could go into full-out panic mode:
85 2. Try to unload the module used by the NIC. While one easily can find
86 the module used by a `$NIC` via `readlink
87 "/sys/class/net/${NIC}/device/driver/module"`, we'd also have to
88 resolve reverse dependencies. For instance, for current Intel
89 wireless chipsets, the `iwlwifi` module is loaded, but with current
90 Linux kernels another module called `iwldvm` is loaded, and it uses
91 `iwlwifi`, so a `morprobe -r iwlwifi` will fail. Sadly `modprobe`
92 doesn't have a `--recursive-remove` or `--show-reverse-depends` so
93 we'd have to e.g. parse "Used by" field of `lsmod` or similar, and
94 we'd have to do it recursively to be rigorous.
95 3. Perhaps prevent NetworkManager from starting if the previous step
97 4. Show a scary error message to the user
99 It would obviously require to drop `set -e`, because errors are indeed
100 what could cause this to happen.
102 ## Detecting MAC-spoof related connection errors for wired NICs
104 While Wi-Fi connection are covered, this gets trickier for wired
105 connections. The problem is that there's no strong concept of being
106 "associated" to a wired network (at least a "standard" one, perhaps
107 there is with 802.1x security...). It'll probably be hard to identify
108 blocking without confusing it with other types of wired connection
109 failures (i.e. false positives). How does wired MAC address blocking
110 usually work? On which level? DHCP? Lower layer?
112 # Old stuff from blueprint
114 ## Improving macchanger
116 Some of our goals would be easier to achieve by patching macchanger
117 itself. Since it's been unmaintained upstream for a while, we've been
118 discussing and working with someone who has taken its maintenance over
119 and has already started patching it to better suit our needs:
121 * [Redmine project](https://labs.riseup.net/code/projects/show/macchanger)
122 * Git repository: `git://labs.riseup.net/backupninja.git`
123 * Debian packages: the maintainer of the macchanger package in
124 Debian has already integrated some of these patches (uploaded to
125 sid: 1.5.0-8) and is likely to go on this way. Tails has been
126 using this improved version for a while.
128 ## Inspiration sources
132 Haven does not automatically start network-manager at boot time.
133 It provides shortcuts in the application menu to run macchanger-gtk
134 and start the network if desired.
138 Liberte Linux randomises wireless MAC addresses at boot time and
139 allows changing wired interfaces' MAC addresses after boot, see their
140 `src/usr/local/sbin/mac-randomize` that uses `ifconfig IFACE hw ether`
141 rather than macchanger.
145 Investigate and possibly document the kind of information that could
146 still be seen on the LAN about the system. Such as the manufacturer (ex:
147 Sony), model number, BIOS and version, etc.?