19/10/13 18:53, intrigeri wrote:
> anonym wrote (09 Oct 2013 16:32:25 GMT) :
>> ## 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.
I had a quick look, essentially copy-pasting the corresponding code from
whisperback, and it was easy. For instance I got a GtkScrolledWindow to
appear between the camouflage and MAC spoofing options, showing the
Tails docs. To make a "Show help/Hide help" label showing/hiding it
wouldn't be that difficult, but it'd work poorly on smaller screens.
Therefore I think the best would be to add "Show help" labels for each
option that, when clicked, will open the documentation in a modal dialog
with a "close" button. The options window would look something like this:
Welcome to Tails
Administrative password Show help
[...]
Windows Camouflage Show help
[...]
MAC spoofing Show help
[...]
Thoughts?
>> ## 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...
>> # 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.
I've verified (using pcap/wireshark) that nothing happens on the network
until NM starts, which does DHCP, using the following chipset/driver
combinations:
* Intel 82579LM with e1000e
* Broadcom NetLink BCM57780 with tg3
> 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.
The computer with Intel 82579LM chipset has vPro and hence AMT. The
previous test was done with AMT disabled. After enabling it (and doing
some further configuration, see below), DHCP was run (and then a web
server was started, enabling remote administration! :S) even before
grub; that would certainly both leak the real MAC address when we don't
want to, and leak a spoofed MAC address when we don't want to.
AMT was enabled by default on my computer, but that only meant that I
could access the Intel(R) Management Engine BIOS Extension and then
further configure AMT to make it actually do anything. I'm pretty sure
this is what Wikipedia means with "Intel vPro PCs can be sold with AMT
enabled or disabled" [1]. I mean, to ship this enabled with the default
password (specified as "admin" by Intel) can't be anything than an OEM
mistake, so I think we at most have to write a short line in the
documentation about this for users that may have enabled it themselves.
[1]
http://en.wikipedia.org/wiki/Intel_Active_Management_Technology#Intel_vPro_PCs_can_be_sold_with_AMT_enabled_or_disabled
> 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.
>> ### 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.
Thanks for the explanation!
I don't know why I didn't come up with "active scanning" as a search
term before. While looking up a bit more about how it works, I found the
following in an article [2] discussing different active probing
algorithms and their parameters (e.g. channel probe order, how many
probes sent per channel, time spend per channel):
Another important encouraging factor is the promising use
of our work in wireless network security. Profiling WNICs
during active scanning can be useful to network administrators
for detecting unauthorized WNICs types. Techniques like
MAC address spoofing and password phishing are known to
easily circumvent security policies. But it is difficult to change
the signature of a WNIC. Such a profiling of wireless hardware
has applications in both military and civilian use.
[2] A Characterization of Wireless NIC Active Scanning Algorithms
<
http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=4224690&tag=1>
They don't elaborate on this "security" aspect any further (maybe it was
just a fishing attempt for some grant money from the military?), but the
key seem to be "WNICs types", i.e. they can only determine WNIC's
chipset and potentially the driver used. IMHO we shouldn't care about
this type of profiling for the same reason we don't spoof the OUI (not
to mention that this type of profiling likely not in use anywhere, and
would be *very* difficult to combat).
> I have no idea how NM behaves on this front.
I have verified (using airodump-ng) that there's no wireless activity
(or packets containing the MAC address, at least) before NM starts,
which does active scanning, using the following chipset/diver combinations:
* Intel Centrino Advanced-N 6205 with iwlwifi
* Broadcom BCM43225 with brcmsmac
I did account for channel hopping by booting Tails once for each channel
in the 2.4 GHz spectrum.
> 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.
> * 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.
>> 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?
If so, I guess we're done with this topic.
>> ### 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. Some comments:
We generate the module blacklist with a build time hook as follows:
find /lib/modules/*/kernel/drivers/net \
-name "*.ko" -printf "blacklist %f\n" | \
sed 's/\.ko$//' | \
sort -u > /etc/modprobe.d/all-net-blacklist.conf
Note that this comes very handy for a "T-G option to completely block
networking" feature. We only have to add a GUI control in T-G,
essentially. :)
We make udev rescan and load the (previously blocked) modules like this:
udevadm trigger --action=add
What this does is just replaying the device events recorded by the
kernel during the "coldplug" time, i.e. when the kernel detects devices
for the first time, before udev is running. AFAICT rerunning this has no
adverse effects. Any arguments to the contrary?
Also, note that this approach makes rfkill blocking of wifi etc. quite
pointless if we take this approach. In fact, the rfkill module will be
blacklisted, so we have to do something with the
tails-set-wireless-devices-state init script. Probably we can just do
that rfkill stuff right after the udev triggering (i.e. put the contents
of the tails-set-wireless-devices-state in the end of
tails-unblock-network in my POC branch), but then blocking of gps would
be delayed. Otherwise we can simply explicitly exclude the rfkill module
from the blacklist.
(Here's a random slightly off-topic thought: maybe gps devices can be
blocked in a similar manner, so we don't have to rely on rfkill? I may
be wrong, but rfkill switches may not always be present (or supported by
the linux kernel).)
> I suspect we could be happy enough with `rfkill block' + testing the
> behavior of a handful of wired devices on boot.
Since the complete network blocking thing I detailed above is quite
simple to implement (merge feature/block-network + adding one line of
code in T-G + dealing with the "old" rfkill stuff, unless I've missed
something severe), the only reason not to do it that I can see is if we
expect it to introduce any hardware-related bugs due to the delayed udev
triggering.
Thanks for the great feedback!
Cheers!
