Hi,
anonym wrote (29 Dec 2013 21:21:35 GMT) :
> 27/12/13 18:05, intrigeri wrote:
[...]
>> I'm afraid this won't work very well for drivers that macchanger can't
>> retrieve the permanent MAC address from, e.g.:
[...]
> However, let's leave this issue a side for a moment,
OK. Filed #6552 so that it doesn't slip through, then.
> The problem
> ===========
> Since the MAC spoofing fail-safe is run only *once*, immediately after
> logging in with Tails Greeter, there's no fail-safe for devices
> hotplugged after logging in.
> [...]
> Approach 1
> ----------
> A seemingly obvious fix would be to move the fail-safe from its current
> location, tails-unblock-network, into tails-spoof-mac, which is run by
> the MAC spoofing udev hook when network devices are added. The fail-safe
> would then act on a per-device basis, and it would be closer to the
> spoofing, which both are nice (bonus: the problem you raised about
> "macchanger can't retrieve the permanent MAC address" would be really
> easy to fix).
I like this approach, and I hope we can make it work fine. Let's see.
> However, a big issue with this approach is that if NetworkManager is
> running when tails-spoof-mac is run by the udev hook (which will be the
> case every time a device is hotplugged after TG login) then there's a
> race: will NM spawn network activity before the fail-safe is triggered
> in case of a MAC spoofing error? This doesn't feel robust at all.
Are you sure NM picks up newly added devices before udev has finished
adding it to the system (which, I hope, is indicated by the fact that
all udev rules have completed their job, which, I hope, includes
running all hooks)? If NM waits for this to be done (and I would hope
so), then this approach is actually not racy at all, is it?
If my guess is wrong, then this approach is definitely racy. We could
mitigate this a little bit by (first thing) disabling the just-added
interface in the script run by the udev hook, with something like:
nmcli dev disconnect iface $IFACE
Potential problems:
* I see this is available in current sid's NM, no idea if that's the
case on Squeeze.
* I see no way to re-enable the device with nmcli, so it would
probably require reloading or SIGHUP'ing or (worst case)
restarting NM once we have spoofed the new NIC's MAC address.
Another similar hack could be to add the newly plugged device to the
list of unmanaged ones, see "Unmanaged devices" on
https://wiki.gnome.org/Projects/NetworkManager/SystemSettings.
Of course, this would still be a bit racy, but perhaps acceptable.
Another hack could be to add to /etc/network/interfaces, at Greeter
time, a broken static configuration snippet for all possible names
that could be used for NICs plugged in the future. IIRC, NM fully
ignores devices that are listed in that file unless they're configured
to use DHCP (not sure what's the current state of the art in Wheezy
and later, but I expect README.Debian to document this). Then, when
a new NIC is plugged in and we have successfully spoofed its MAC
address, then we can remove the corresponding configuration snippet
and gently ask NM to manage it, with a NM reload or SIGHUP or — worst
case — restart. Ugly and not that easy to get right (listing the names
would be a pain, to start with), yeah, but probably more robust in the
end than the other ideas raised in approach #1. Still, I hope we can
avoid this.
> Approach 2
> ----------
> An alternative fix that would keep the robustness of the current
> implementation (in fact, very little in the current implementation would
> change, at least compared to Approach 1) would be to disallow
> hotplugging of network devices after TG login. While this will add some
> user inconvenience, I think it's acceptable
Fully agreed.
More specifically though, this would bring one (minor) UX issue:
careful people have got used to 1. boot Tails; 2. login; 3. stop NM;
4. plug their NIC; 5. spoof the MAC for their NIC; 6. start NM. So,
they would need to change their existing habits entirely, and plug the
NIC before booting. I think that can very well be addressed by a tiny
bit of documentation, which we'll need anyway if we go with
this approach.
> (also, it's pretty close to
> some of the proposed solutions for bug #5451: protect against external
> bus memory forensics).
First, I expect that most such hotplugged NICs are either USB, or
plugged into a bus we want to disable post-login as part of #5451.
The latter doesn't matter much IMO yet (since it'll be disabled at
a lower level at some point, and until we complete #5451, there's
little point in protecting against this at the NIC level only).
For USB NICs, that's a different matter.
On the one hand, we have not considered disabling USB devices hotplug
as part of #5451, mostly because 1. USB doesn't do DMA (right?) and 2.
many usecases we want to support, e.g. Tails Installer, depend on the
ability to do so. So, I doubt we'll ever want to disable USB hotplug
entirely post-login.
On the other hand, assuming we disable USB NICs hotplugging via udev,
but keep supporting hotplug for other kinds of USB devices, then we
don't add much protection: the recent flow of issues discovered by
Kees Cook in Linux regarding USB drivers were mostly found in the HID
layer, and I suspect the underlying USB controller drivers may have
similar issues.
So, I must say I don't buy this side argument (closeness with #5451)
at all. Of course, I understand you didn't mean this to be a decisive
one :)
> The problem with this approach is how to disallow hotplugging. Simply
> restoring the blacklist isn't very robust; since the blacklist works on
> the module loading (modprobe) level, devices that happen to use the same
> module as a device that was added before TG login can then be
> successfully hotplugged even after TG login.
I don't think we should disregard this idea entirely. I think the
problematic situations are very much corner cases in practice:
1. It's quite unlikely to happen in practice: first, it requires
this special combination of NICs, that's itself pretty unlikely;
second, if MAC spoofing worked for the NIC plugged in early,
there are great chances it works to for the NIC plugged
post-login, since both use the same driver. So, the lack of
a fail-safe in this edge case doesn't seem critical to me.
2. The failure mode I would expect to be the most frequent (MAC
spoofing fails for both the NIC plugged pre-login and the one
plugged post-login, since they use the same driver) is not
a problem in practice: if MAC spoofing fails for a NIC plugged
pre-login, then we already unload the corresponding module with
our fail-safe code. This, combined with restoring the blacklist,
would prevent the post-login NIC to be enabled.
3. For the worst failure mode (MAC spoofing works for the NIC
plugged pre-login, but fails for a NIC hotplugged later despite
they use the same driver), that I expect to be very rare, then
I expect the kind of (power-)users who play with multiple NICs to
be able to use rfkill as a minimal safe-guard, or refrain from
plugging a network cable too early, and then verify themselves
that MAC spoofing was successful, especially once this potential
problem is documented.
So, I think it would be acceptable to document as a known issue that
NIC hotplug works after login (while it ideally shouldn't) *and* lacks
the "fail-safe" verification *if* it uses the same kernel driver as
another NIC that was already plugged in at Greeter time. I'm playing
my "let's be pragmatic" magic card!
> Does any one know of an alternative to "ignore_device"?
I couldn't find any :(
> What to do?
> ===========
> If we cannot solve the problems in Approach 1 or 2 (and cannot come up
> with a superior Approach 3) then I guess we will have to pick whatever
> we consider the least bad of those two, and perhaps document that
> hotplugging after TG login isn't safe w.r.t. MAC spoofing.
Another approach (that only works for USB devices) worth looking at is
the Linux USB authorization support:
* Documentation/usb/authorization.txt
*
http://www.irongeek.com/i.php?page=security/plug-and-prey-malicious-usb-devices#3.2_Locking_down_Linux_using_UDEV
So, my current position is: if approach #1 is doable in a non-racy way
(i.e. if NM does not picks up a new device before udev is done with
it), then let's KISS and just do it. Else, either go with approach #2,
or with approach #1 (in a bit racy way), that both require documenting
the limitations in rare, edge cases.
Cheers!
--
intrigeri
| GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
| OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
