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. Cheers! _______________________________________________ tails-dev mailing list [email protected] https://mailman.boum.org/listinfo/tails-dev
