summaryrefslogtreecommitdiffstats
path: root/wiki/src/blueprint/macchanger.mdwn
blob: 7663a35771e7f000739100641f964f68659f06c5 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
[[!toc levels=2]]

# Future work

## Using NetwokManager for AvoidConnectionProbs?

Instead of our current hack, we'd ideally want to hook into
NetworkManager's error handling, which certainly would be more robust,
and hopefully would provide more information about the error, but this
currently seems unsupported.

An experiment has showed that when connecting to a password-protected
(WPA-PSK) wireless network with MAC address white-listing, spoofed
(and hence blocked) MAC addresses resulted in an endless cycle of NM
asking for passphrase. When cancelled, NM displays a "Disconnected"
notification, and during this time no NM dispatcher events were
emitted.

Some bugs of interest that may bring some hope:

* [[!gnomebug 387832]] resolved
* [[!debbug 518368]] fixed upstream
* <https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/336736> wontfix

## Vendor bit randomisation with macchiato

These are the current relevant OUI counts from macchiato's git:

5       oui/bluetooth_laptop.sh
2       oui/bluetooth_misc.sh
12      oui/bluetooth_mobile.sh
1       oui/bluetooth_pmp.sh
2       oui/wired_console.sh
3       oui/wired_desktop_dedicated.sh
11      oui/wired_desktop_onboard.sh
8       oui/wired_infrastructure.sh
17      oui/wired_laptop.sh
6       oui/wired_misc.sh
4       oui/wired_printer.sh
2       oui/wireless_camera.sh
1       oui/wireless_console.sh
4       oui/wireless_desktop_dedicated.sh
2       oui/wireless_desktop_onboard.sh
4       oui/wireless_handheld.sh
6       oui/wireless_infrastructure.sh
1       oui/wireless_laptop_dedicated.sh
21      oui/wireless_laptop.sh
17      oui/wireless_mobile.sh
7       oui/wireless_pmp.sh
4       oui/wireless_printer.sh
8       oui/wireless_usb.sh

In particular there's ~20 each in wireless_laptop and wired_laptop,
which is what we should care about most (desktops rarely need MAC
spoofing). However, after investigating the sources for some OUI:s
(via git history), some OUI:s are (according to the submitter) only
common in certain geographical areas. This makes the lists too small
and unreliable at the moment.

There are others attempts at collecting MAC addresses for various
kinds of hardware:

* [Boruch-Baum's mac_changer_choice](https://github.com/Boruch-Baum/mac_changer_choice)
* Subgraph's ouiner
  ([Bitbucket](https://bitbucket.org/mckinney_subgraph/ouiner),
  [GitHub](https://github.com/mckinney-subgraph/ouiner))
  whose data is used by
  Macouflage ([Bitbucket](https://bitbucket.org/mckinney_subgraph/macouflage),
  [GitHub](https://github.com/subgraph/macouflage))

# Questions, remaining issues, and other random stuff

## MAC spoof failure warning and failsafe

If MAC spoofing fails for some interface we'd like to prevent it from
exposing the real MAC address, and warn the user about this via a
notification.

In the current implementation there's no failsafe that verifies that
the selected MAC spoofing setting has been enforced before
connecting. This would be easy if there was something like pre-up NM
dispatcher hooks but just like in the section about "Connection
failure detection", there's none yet.

An alternative would be to do this in
[[!tails_spoof-mac_gitweb config/chroot_local-includes/usr/local/sbin/tails-spoof-mac]], which
is run by the udev hook. In the end of the script we could try to
verify that the spoofing indeed happened for the NIC in question, and
if it didn't we could go into full-out panic mode:

1. Down the interface
2. Try to unload the module used by the NIC. While one easily can find
   the module used by a `$NIC` via `readlink
   "/sys/class/net/${NIC}/device/driver/module"`, we'd also have to
   resolve reverse dependencies. For instance, for current Intel
   wireless chipsets, the `iwlwifi` module is loaded, but with current
   Linux kernels another module called `iwldvm` is loaded, and it uses
   `iwlwifi`, so a `morprobe -r iwlwifi` will fail. Sadly `modprobe`
   doesn't have a `--recursive-remove` or `--show-reverse-depends` so
   we'd have to e.g. parse "Used by" field of `lsmod` or similar, and
   we'd have to do it recursively to be rigorous.
3. Perhaps prevent NetworkManager from starting if the previous step
   failed?
4. Show a scary error message to the user

It would obviously require to drop `set -e`, because errors are indeed
what could cause this to happen.

## Detecting MAC-spoof related connection errors for wired NICs

While Wi-Fi connection are covered, this gets trickier for wired
connections. The problem is that there's no strong concept of being
"associated" to a wired network (at least a "standard" one, perhaps
there is with 802.1x security...). It'll probably be hard to identify
blocking without confusing it with other types of wired connection
failures (i.e. false positives). How does wired MAC address blocking
usually work? On which level? DHCP? Lower layer?

# Old stuff from blueprint

## Improving macchanger

Some of our goals would be easier to achieve by patching macchanger
itself. Since it's been unmaintained upstream for a while, we've been
discussing and working with someone who has taken its maintenance over
and has already started patching it to better suit our needs:

* [Redmine project](https://labs.riseup.net/code/projects/show/macchanger)
* Git repository: `git://labs.riseup.net/backupninja.git`
* Debian packages: the maintainer of the macchanger package in
  Debian has already integrated some of these patches (uploaded to
  sid: 1.5.0-8) and is likely to go on this way. Tails has been
  using this improved version for a while.

## Inspiration sources

### Haven

Haven does not automatically start network-manager at boot time.
It provides shortcuts in the application menu to run macchanger-gtk
and start the network if desired.

### Liberte Linux

Liberte Linux randomises wireless MAC addresses at boot time and
allows changing wired interfaces' MAC addresses after boot, see their
`src/usr/local/sbin/mac-randomize` that uses `ifconfig IFACE hw ether`
rather than macchanger.

## Documentation

Investigate and possibly document the kind of information that could
still be seen on the LAN about the system. Such as the manufacturer (ex:
Sony), model number, BIOS and version, etc.?