27/12/13 18:05, intrigeri wrote:
> anonym wrote (22 Dec 2013 15:08:56 GMT) :
>> 29/11/13 12:31, intrigeri wrote:
>> +get_permanent_mac_of_nic() {
>> + macchanger ${1} | sed -n "s/^Permanent\s*MAC:\s*\([0-9a-f:]\+\)\s.*$/\1/p"
>> +}
>> [...]
>> +nic_has_spoofed_mac() {
>> + [ "$(get_permanent_mac_of_nic ${1})" != "$(get_current_mac_of_nic ${1})" ]
>> +}
>
> I'm afraid this won't work very well for drivers that macchanger can't
> retrieve the permanent MAC address from, e.g.:
>
> $ sudo macchanger eth0
> ERROR: Can't read permanent MAC: No such device
> Permanent MAC: 00:00:00:00:00:00 (Xerox Corporation)
> Current MAC: f0:de:f1:11:11:11 (Wistron Infocomm (kunshan)co)
Thanks for pointing this out. I didn't know this was true for some devices.
> I'm unsure what special casing can be done about it, but it would be
> great to avoid *always* concluding such a NIC has a spoofed MAC.
>
> Maybe we should simply save the original MAC before attempting to
> spoof it, and compare later?
Right. To clarify, we'd need to save the MAC address to somewhere in the
filesystem in `tails-spoof-mac` (called by the MAC spoof udev hook)
since we also need the functionality of `nic_has_spoofed_mac()` in the
fails-safe in `tails-unblock-network`.
However, let's leave this issue a side for a moment, because I just
realised that there's a severe issue with having the fail-safe in
tails-unblock-network (at least in the current state of things).
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.
Solution
========
At the moment I only have bad or partial solutions:
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).
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.
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 (also, it's pretty close to
some of the proposed solutions for bug #5451: protect against external
bus memory forensics).
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.
For robustness we'd have to move from the blacklist to something
lower-level. I've looked into what's possible to do with udev rules.
What I'd like is to write a rule which would make udev completely ignore
network devices, so they would remain disabled. That rule would be
*temporarily* removed in tails-unblock-network so all network devices
present at that particular time will be probed and activated. However, I
can't find a way to do this in current udev as all ways to do this seem
to have been deprecated, like the following:
SUBSYSTEM=="net",
ACTION=="add",
ATTR{type}=="1",
OPTIONS+="ignore_device"
The "ignore_device" OPTION was deprecated in udev 148 (and perhaps it
didn't do what I wanted any way). Does any one know of an alternative to
"ignore_device"?
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.
I'm all ears for any input! Meanwhile I'll continue looking for
solutions and alternative approaches.
Cheers!
