Re: [Tails-dev] [RFC] Design (and prototype) for MAC spoofin…

24/10/13 16:34, anonym wrote:
> 19/10/13 18:53, intrigeri wrote:
>> anonym wrote (09 Oct 2013 16:32:25 GMT) :
>>> ## Connection failure detection
[...]
>> A painful, ugly and not-so-robust way would be to set up a listener on
>> the relevant logging facility and grep it, and then report such
>> failures to the user and point them to documentation explaining that
>> it *might* be caused by MAC spoofing? (E.g. "if you usually
>> successfully connect to this very network with this very computer and
>> another OS, then you might want to try disabling MAC spoofing and see
>> if it helps".)
>>
>> Anyway, let's just ship the first iteration without any specific
>> support for this case, see what happens, and then re-prioritize this
>> topic in function of the amount of user confusion and support work
>> triggered by the default settings.
>
> Urgh, ok. Seems like both NetworkManager and wpa_supplicant (at least
> for WPA) logs connection state changes and events to syslog. I'll look
> into all combinations of {no security, WPA, WEP} x {no blocking, MAC
> blocking} x {correct password, incorrect password} to see if we first of
> all can detect errors, and preferably if we also can distinguish an
> error caused by giving an incorrect password from other types of errors.
> Any other factors you can think of that I should look into?
>
> To be continued...

I found a way to do this for wifi connections only, and pushed it in
commit 8457af1 to the feature/spoof-mac Tails branch. I also pushed
commit 5c32c63 to feature/spoof-mac in Tails Greeter, which starts this
new "network blocking detector".

I'm unsure of how to proceed for wired connections. The problem is that
there's no strong concept of being "associated" to a wired network (at
least a "standard" ones, perhaps there is with 802.1x security...). I
haven't really looked into this deeply but I suspect it'll be hard to
identify blocking without confusing it with other types of wired
connection filures. If any one has good clues about how wired MAC
address blocking works (e.g. on which level. DHCP? Lower layer?) I'd
appreciate hearing about it.

Funny side-note: MAC spoofing apparently breaks both NAT-based and
bridge-based networking in VirtualBox (it works well in libvirt/KVM
though). We may want to add a specific notification if we detect that
Tails is run in VirtualBox on network failure.

Also, I haven't been able to investigate this for WAN connections (e.g.
3g) since I don't have access to anything like that, and hence no NM
logs. Any way, since I wouldn't be in control of whatever server I'd
authenticate to I wouldn't be able to make it block my MAC address, and
hence I wouldn't get logs for that case, only for success, and failure
due to bad credentials.

>>> ### 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.

Oops, seems like I forgot to push the branch :S. Pushed now, but
rewritten, so the commit in question is 3c77a07.

I've also pushed a Tails Greeter branch
feature/spoof-mac-with-block-network (branched from feature/spoof-mac),
which makes use of both Tails branches feature/spoof-mac and
feature/block-network. So, if you build a Tails with both those
branches, and use a T-G built from the one branch, then you get my
vision of how this all could work. I don't have the time now, but I may
prepare a feature/spoof-mac-experimental with all this (including a
packaged .deb in its APT suite) to make things easier for reviewers.

Cheers!