Author: anonym Date: To: The Tails public development discussion list Subject: Re: [Tails-dev] [RFC] Design (and prototype) for MAC spoofing in
Tails
24/10/13 16:34, anonym wrote: > 19/10/13 18:53, intrigeri wrote:
>> Hardware with Intel AMT (or is it vPRO?) or similar firmware-level
>> backdoors^Wuseful remote administration features would be the first
>> thing I investigate, if I had to dig further in this direction.
>
> The computer with Intel 82579LM chipset has vPro and hence AMT. The
> previous test was done with AMT disabled. After enabling it (and doing
> some further configuration, see below), DHCP was run (and then a web
> server was started, enabling remote administration! :S) even before
> grub; that would certainly both leak the real MAC address when we don't
> want to, and leak a spoofed MAC address when we don't want to.
Correction: This can only leak the real MAC address, not the spoofed
one, obviously.
>>> ### Completely block network devices until T-G post-login?
>>
>>> If we block all network devices from being added by udev until after
>>> T-G has logged in (when we known the user's MAC spoof preference) then
>>> the whole "early leaks of spoofed MAC addresses" issue would be
>>> solved, provided the user did the right choice. Maybe this is
>>> worthwhile?
>>
>> This would be the best, yeah. I suggest you spend max. 2 hours
>> investigating if/how this can be done, and then report back on the
>> expected amount of work you think it would be. I must say I'm
>> intuitively quite scared of the various potential unexpected
>> complications this could bring.
>
> What comes to mind is to blacklist all network modules in
> /etc/modprobe.d. This blacklist is removed after T-G login, and then we
> ask udev to scan for devices again. See the branch feature/block-network
> for a POC (read the commit message of 1e71e1f for how to test), which
> I've tested successfully. Some comments: [...] > Also, note that this approach makes rfkill blocking of wifi etc. quite
> pointless if we take this approach.
Clarification: With "wifi etc" I meant only wireless *networking*
devices that we block, not gps, bluetooth etc.
> In fact, the rfkill module will be
> blacklisted, so we have to do something with the
> tails-set-wireless-devices-state init script. Probably we can just do
> that rfkill stuff right after the udev triggering (i.e. put the contents
> of the tails-set-wireless-devices-state in the end of
> tails-unblock-network in my POC branch), but then blocking of gps would
> be delayed. Otherwise we can simply explicitly exclude the rfkill module
> from the blacklist.
Correction: The rfkill module will *not* be blacklisted. It's located in
kernel/net, not kernel/drivers/net (which we blacklist all drivers
from), so the problem reported above is invalid. In other words, all is
good w.r.t. tails-set-wireless-devices-state in feature/block-network.
