Project

General

Profile

Bug #16560

MAC spoofing failure sometimes does not disable networking

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

Status:
Resolved
Priority:
High
Assignee:
-
Category:
Spoof MAC
Target version:
Start date:
03/15/2019
Due date:
% Done:

0%

Feature Branch:
Type of work:
Research
Blueprint:
Starter:
Affected tool:

Description

In some of our most constrived test suite scenarios ("MAC address spoofing fails and macchanger returns true" and "MAC address spoofing fails and the module is not removed") I've recently seen failures: the network interface or NetworkManager is left enabled.

I've seen this happen with both systemd v240 and v241, and both Linux 4.19.20 and 4.19.28.

In passing, I wonder if we should give MACAddressPolicy= a try (systemd.link(5)), let udev set a random MAC address, and keep only our code that detects whether the MAC address was successfully spoofed and if not, switches to "panic mode".

01_45_10_MAC_address_spoofing_fails_and_macchanger_returns_true.journal (245 KB) intrigeri, 03/15/2019 07:44 AM

01_45_27_MAC_address_spoofing_fails_and_the_module_is_not_removed.journal (252 KB) intrigeri, 03/15/2019 07:44 AM

debug.log View (13.2 KB) intrigeri, 03/15/2019 07:44 AM


Related issues

Related to Tails - Bug #16620: Wi-Fi passphrase prompt is sometimes not displayed on Buster Resolved
Blocks Tails - Feature #16209: Core work: Foundations Team Confirmed 03/22/2019

History

#1 Updated by intrigeri 4 months ago

#2 Updated by intrigeri 3 months ago

  • Priority changed from Elevated to High
  • Target version deleted (Tails_3.14)

#3 Updated by segfault about 2 months ago

I don't understand what should cause NetworkManager to be disabled in the scenario "MAC address spoofing fails and macchanger returns true". In mac_spoof_panic() in tails-spoof-mac, we unload the NIC module. Then we start NetworkManager in tails-unblock-network.

In my Tails 3.14 VM, when I stop NM, manually unload the NIC module, and then start NetworkManager again, it also just starts (and I can't connect to the network).

#4 Updated by intrigeri about 2 months ago

I don't understand what should cause NetworkManager to be disabled in the scenario "MAC address spoofing fails and macchanger returns true". In mac_spoof_panic() in tails-spoof-mac, we unload the NIC module. Then we start NetworkManager in tails-unblock-network.

I think the answer is in this comment in config/chroot_local-includes/usr/local/lib/tails-unblock-network:

# If tails-spoof-mac goes into panic mode but fails to disable the
# problematic device, the NetworkManager services will be masked.

It refers to stop_and_disable_NM in config/chroot_local-includes/usr/local/lib/tails-spoof-mac.

In my Tails 3.14 VM, when I stop NM, manually unload the NIC module, and then start NetworkManager again, it also just starts (and I can't connect to the network).

That's because the panic mode code that masks the NM services hasn't run, right?

#5 Updated by segfault about 2 months ago

intrigeri wrote:

I don't understand what should cause NetworkManager to be disabled in the scenario "MAC address spoofing fails and macchanger returns true". In mac_spoof_panic() in tails-spoof-mac, we unload the NIC module. Then we start NetworkManager in tails-unblock-network.

I think the answer is in this comment in config/chroot_local-includes/usr/local/lib/tails-unblock-network:

# If tails-spoof-mac goes into panic mode but fails to disable the
# problematic device, the NetworkManager services will be masked.

It refers to stop_and_disable_NM in config/chroot_local-includes/usr/local/lib/tails-spoof-mac.

Yes, I saw that. But I thought that's what should happen when the module can't be unloaded, i.e. in the "MAC address spoofing fails and the module is not removed" scenario. I thought that in the "MAC address spoofing fails and macchanger returns true" scenario, the module unloading works and therefore the service is not masked. Is this is not correct?

In my Tails 3.14 VM, when I stop NM, manually unload the NIC module, and then start NetworkManager again, it also just starts (and I can't connect to the network).

That's because the panic mode code that masks the NM services hasn't run, right?

The way I understand it, the NM services are not supposed to be masked if the modules can be unloaded.

#6 Updated by intrigeri about 1 month ago

segfault wrote:

I thought that in the "MAC address spoofing fails and macchanger returns true" scenario, the module unloading works and therefore the service is not masked. Is this is not correct?

Indeed, you're entirely right and I was confused! mac_spoof_panic() only disables NetworkManager if the module unloading fails. I think the intent is that on a system with two network interfaces, one of which we fail to spoof the MAC address of, we want to allow the user to use the other network interface, if we successfully spoofed its MAC address. But in the end that's irrelevant, because our test suite does not assume anything else, and as you can see in the attached debug.log, the step that fails is "no network interfaces are enabled".

So:

  • "MAC address spoofing fails and the module is not removed" → the attached debug.log shows LoadState=loaded (while our test suite expects LoadState=masked) and ActiveState=inactive (as expected), which demonstrates there's a bug: NetworkManager was not masked.
  • "MAC address spoofing fails and macchanger returns true" → the "no network interfaces are enabled" fails

Next step: figure out if these failures are caused by a bug in our test suite. Given the "sometimes" aspect, I bet there's a race condition. I suspect that's because on Tails 3.x, the Greeter runs /usr/local/lib/tails-unblock-network in the background in PostLogin.default, which might cause the "But the MAC spoofing panic mode disabled networking" step to run before mac_spoof_panic() has finished its job, and perhaps we did not notice this when we decided to run that script in the background; on Buster I've reverted this to running tails-unblock-network in a blocking manner (91009b5a39884d4c90cf0d458eba454ed6c1a3fd), so if my hunch is correct, then this scenario should be robust on feature/buster ⇒ next step is to check whether that's the case and if yes, close this with target version = 4.0 (don't bother about 3.x).

segfault, does this make sense to you?

#7 Updated by intrigeri about 1 month ago

  • Related to Bug #16620: Wi-Fi passphrase prompt is sometimes not displayed on Buster added

#8 Updated by intrigeri about 1 month ago

  • Status changed from Confirmed to Needs Validation
  • Target version set to Tails_4.0

if my hunch is correct, then this scenario should be robust on feature/buster ⇒ next step is to check whether that's the case

The first Jenkins job run with the commit that might fix this on feature/buster is https://jenkins.tails.boum.org/view/RM/job/test_Tails_ISO_feature-buster/124/. Since then, this job has been run 94 times. I've checked every one of those where either of the two scenarios this ticket is about failed, which happened 3 times. Each of these failures was caused by "virt-viewer failed to start" or "Remote shell seems to be down", i.e. the bug this ticket is about never happened in these 94 test suite runs.

and if yes, close this with target version = 4.0 (don't bother about 3.x).

Given my analysis above, I think we should do that.

@segfault or @anonym, can one of you please check my reasoning and if you agree, close this ticket as resolved?

#9 Updated by segfault about 1 month ago

  • Status changed from Needs Validation to Resolved

intrigeri wrote:

@segfault or @anonym, can one of you please check my reasoning and if you agree, close this ticket as resolved?

I agree with your reasoning

Also available in: Atom PDF