Re: [Tails-dev] [Secure Desktops] Tails' MAC 'leak preventio…

[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!