[Sorry for the delay :S] Patrick Schleizer: > I understand Tails' MAC 'leak prevention' [1] [2] as this... Without > 'leak prevention', things would happen like this: > > a) > > 1) system boots > 2) kernel module loaded > 3) MAC leaked > 4) macchanger started > 5) MAC changed > 6) NetworkManager started > > So the MAC leaked even before NetworkManager, before the the interface > has been uped, before macchanger may have had a chance to change it. > > Therefore Tails does as this: > > b) > > 1) system boots with kernel modules blacklisted > 2) user makes decision [to spoof MAC] > 3) MAC changed > 4) kernel module loaded > 5) NetworkManger started > > But if there hypothesis was true... They still have a small window > between tails-unblock-network, service network-manager start and macchanger. > > Can the MAC be changed without having the kernel module loaded? > - if yes -> great > - if no -> then there would be room for MAC leaks like in a), right?
None of your scenarios really reflect what happens in Tails implementation, at least. The key thing that prevents this "window" is that we have an udev hook triggering on added network devices that will execute the MAC spoofing script. udev won't advertise the device as finished until all such hooks have exited (or timed out) so NetworkManager won't touch the device. It is true, though, that the device is usable, so something else could use the device and leak the MAC address. I suppose our design docs are not clear on this point. > Quote Tails Design > >> It is conceivable that NICs may send packets before the user has made > a decision about whether to use MAC spoofing or not. In fact, someone on > tails-dev@ alluded [3] to this being possible for wireless NICs although > without any references (this may refer to so called "active probing"; > see section below). If this is the case it at the very least implies > that we must enforce the MAC spoofing setting as early as possible. [...] > > That does not sound very certain. > > Just because of being alluded [3] you done quite some effort to not load > the kernel modules? Indeed, that paragraph should be rewritten some how or just dropped. We know that Intel AMT/vPro can do stuff like this, and that we cannot do anything about (which we do mention), and I have no idea why we mix "active probing" there which seems completely unrelated. The point of that section is just to arrive at the still sound conclusion that the decision has to be made first. > Wouldn't it be possible, and simpler, to block all networking with > iptables to prevent early MAC leaks so kernel module blacklisting could > be avoided? I'm not sure it would be simpler. The module blocking approach definitely makes some other parts of the implementation simpler and decoupled so the MAC spoofing system more or less can be plugged into the existing Tails without modifying other parts. For instance, we have a lot of NetworkManager hooks that run when a device is up:ed. What should we do during the time they are blocked? Of course, we could make the very first hook wait until some signal that means that device is ready. The point is that it becomes harder to reason when we add yet another state a network device can be in. Also, it feels safer to rely on the lack of code (i.e. no module loaded) than more code (iptables (via ferm) and netfilter blocking absolutely everything for some device, even low-level wireless active probing etc). Also note that we want to support hotplugging network devices safely (w.r.t. MAC spoofing) after boot and logging in, so the firewall rules would have to be updated dynamically upon when a device is added (and removed!), which seems complex and makes me feel a bit uneasy. That said, this is certainly open for discussion. Cheers! _______________________________________________ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.