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
