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