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?
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?
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?
Cheers,
Patrick
[1]
https://tails.boum.org/contribute/design/MAC_address/#index5h1
[2]
http://www.webcitation.org/6dJWAQUDz
[3]
https://mailman.boum.org/pipermail/tails-dev/2013-January/002491.html
