Hi,
anonym wrote (24 Oct 2013 14:34:01 GMT) :
> 19/10/13 18:53, intrigeri wrote:
>> anonym wrote (09 Oct 2013 16:32:25 GMT) :
>>> ## Documentation access in Tails Greeter
> [...]
> Welcome to Tails
> Administrative password Show help
> [...]
> Windows Camouflage Show help
> [...]
> MAC spoofing Show help
> [...]
Looks good to me at first glance. We'll want some HCI expert to review
all this at some point when we revamp the greeter UI anyway.
>>> ## Connection failure detection
>>
>>> I've failed to find a way to hook into NetworkManager's connection
>>> error handling. An experiment showed that when connecting to a
>>> password-protected (WPA-PSK) wireless network with MAC address
>>> white-listing, spoofed (and hence blocked) MAC addresses resulted in
>>> an endless cycle of NM asking for passphrase. When cancelled, NM
>>> displays a "Disconnected" notification, and during this time no NM
>>> dispatcher events were emitted.
>>
>>> Unfortunately I'm not sure we can do this one without some serious
>>> patching of NetworkManager. Some bugs of interest that may bring some
>>> hope:
>>
>>> * <https://bugzilla.gnome.org/show_bug.cgi?id=387832>
>>> * <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=518368>
>>> * <https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/336736>
>>
>> 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...
Perhaps it's premature, but at some point you'll want to add this
stuff to the relevant blueprint.
>>> # Questions, remaining issues, and other random stuff
>>
>>> ## Leaking spoofed MAC address on public computer?
>> [...]
>>> ### Is there any wired activity before T-G?
[...]
>> I'm not sure how much this should be blocking the release of a first
>> iteration of this work. What do others think?
> Given the above results, I believe we're done with this topic.
OK.
>>> ### Is there any wireless activity before T-G?
>>
>>> In our blueprint it's stated that: "Network manager will automatically
>>> begin to scan the network with a non-fake mac address". This implies
>>> that scanning is active, not passive.
>>
>> AFAIK Wi-Fi has two scanning modes: a passive one and an active one.
>> When active scanning is used, "probe request":s are sent for every
>> known Wi-Fi network (which is especially problematic if NM persistence
>> is enabled). My (limited) understanding is that active probe requests
>> are generally used 1. to save power, e.g. on smartphones; and 2.
>> to display known "hidden" AP:s in a Wi-Fi configuration widget.
> [...]
>> So:
>>
>> * On the "wireless activity before the Greeter" front: I think we
>> should just rfkill block these devices as early as possible
>> anyway, so case closed IMHO.
> I suppose this could be added as a safeguard in case some hardware (or
> its driver) behaves differently, like a driver that sends active probes
> on its own, without being asked by any user-space tool (like NM). This
> seems unlikely, though.
If I understood correctly, at least the (injected) firmware side is
covered by the new network blocker anyway. IMHO that's the best we can
do, so case closed..
>> * On the AdvGoalTracking and AdvGoalProfiling fronts, MAC spoofing
>> alone is not enough (when NM persistence is enabled), unless we
>> make sure NM doesn't use active scanning (hopefully this doesn't
>> seriously break any usecase).
>>
>> After a quick look, I think that grep'ing the NM source for
>> scan_ssid should be enough to point to the relevant pieces of
>> code. It would be great to do this on Squeeze, Wheezy and current
>> upstream Git, as I have empirical reasons to suspect that the
>> behavior may have changed, and we don't want to see our nice
>> design silently broken by the move to Wheezy.
>>
>> Although not strictly related to MAC spoofing, given the user
>> goals expressed in this design, IMHO this has to be addressed in
>> the first released iteration of this work.
> Unless we plan to start NM earlier than T-G's post-login, we can skip this.
I'm not convinced. Even with a spoofed MAC, NM with persistent
connections still is subject to AdvGoalProfiling and to a more general
version of AdvGoalTracking that can be expressed as "monitoring of an
individual's geographical movement". Is this is fixed somehow and I've
missed it?
>>> Is this what [3] alludes to?
>>
>> Assuming you really mean [2] here: I've no idea. As such leaks can
>> only be triggered by drivers and (closed source) firmware, the only
>> way I see to have any kind of certainty on this is to actually monitor
>> the relevant Wi-Fi channels (with as many monitoring devices as
>> needed, because channel hopping may be too slow to discover the leak)
>> while a few Wi-Fi devices of different brands are powered up.
> Do you think my test with the two above chipsets is enough?
Good enough, especially since the new network blocker solves most
of this.
> If so, I guess we're done with this topic.
Modulo active scanning (see above), I agree.
I'll try to test the branch in the next few days.
To end with, I notice the blueprint was not updated (modulo typos etc.
I fixed) since almost a month. At some point, you'll want to make it
include all the good thinking that was put into the
recent discussions.
Cheers,
--
intrigeri
| GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
| OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
