Hi, anonym wrote (09 Oct 2013 16:32:25 GMT) : > Below are the initial design after an internal discussion. > [...] > All comments are welcome!
First, congrats for this amazing piece of work! > # Future work (/me deleting most of his previous comments, as they are addressed in this section :) > ## Documentation access in Tails Greeter > For this Tails Greeter option, and similar complicated options to > come, it would be very handy to be able to access the appropriate > documentation inside Tails Greeter, similar to how we do it in > Whisperback. Agreed. I'm not sure it qualifies as "future work", though, if we have no other proper way to explain edge cases to the user. But perhaps the required UI design sets the bar too high for a first iteration. I'm unsure, and would like to hear from others on that one. > ## 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. > ## Pre-up Failsafe > In the current implementation there's no failsafe that verifies that > the selected MAC spoofing setting has been enforced before > connecting. This would be easy if there was something like pre-up NM > dispatcher hooks but just like in the previous section, there's none > yet. > # Questions, remaining issues, and other random stuff > ## Leaking spoofed MAC address on public computer? [...] > ### Is there any wired activity before T-G? Given we can't rfkill block these ones, and what (closed source) firmware do is out of our control, I think the only way to get any satisfying level of certainty on that one is to sniff outgoing network traffic of a few wired Ethernet devices of different brands and models while they are powered up. 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. I'm not sure how much this should be blocking the release of a first iteration of this work. What do others think? > ### 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. I have no idea how NM behaves on this front. 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. * 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. > 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. This seems unnecessarily painful to me, with a limited level of certainty in the end, so presumably it will be much cheaper to rfkill block devices before the spoofing decision is made. > ### Should we rfkill wifi? > Especially if the previous question has a positive answer, maybe we > should make a udev hook for when the rfkill switch device is added by > udev (assuming that it's possible) that blocks wifi. After Tails Greeter > logs in, we'd then unblock it. I think we should just do it. > ### 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. I suspect we could be happy enough with `rfkill block' + testing the behavior of a handful of wired devices on boot. Note that if "clever" wired devices (AMT, vPRO, whatever) leak the "real" MAC address before the OS is booted, there's nothing we can do about it, so there's a limit to the level of protection we can offer against early hardware leaks. It doesn't mean we shouldn't do our best to avoid leaking stuff once we're in control, but it helps putting things into perspective. 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
