Project

General

Profile

Bug #17128

Investigate whether internal network adapters consistently use their previously spoofed MAC address after resuming from suspend

Added by intrigeri about 1 month ago. Updated about 1 month ago.

Status:
Confirmed
Priority:
Normal
Assignee:
-
Category:
Spoof MAC
Target version:
-
Start date:
Due date:
% Done:

0%

Feature Branch:
Type of work:
Security Audit
Blueprint:
Starter:
Affected tool:

Description

On resume, apparently internal network adapters are not seen as "added" by the kernel, so no udev event is triggered, so we don't spoof their MAC address again.
So it seems we're implicitly relying on the assumption that all internal network adapters and their firmware will remember and use their previously spoofed MAC after resuming from suspend.
Is this actually true?

Note that if we let NetworkManager handle the whole MAC spoofing dance itself (#11293), we would not have to wonder.


Related issues

Related to Tails - Bug #17115: MAC spoofing can fail and disable a network adapter when waking up from suspend Confirmed
Related to Tails - Feature #11293: Check if/how we should use NetworkManager's new MAC address spoofing capabilities Confirmed 03/31/2016

History

#1 Updated by intrigeri about 1 month ago

  • Related to Bug #17115: MAC spoofing can fail and disable a network adapter when waking up from suspend added

#2 Updated by intrigeri about 1 month ago

  • Related to Feature #11293: Check if/how we should use NetworkManager's new MAC address spoofing capabilities added

#3 Updated by intrigeri about 1 month ago

One data point: the wired Ethernet adapter in a ThinkPad X200 keeps its previously spoofed MAC address after resuming from suspend. But of course, that does not fully answer the question this ticket is about.

Also available in: Atom PDF