Tails

#3 Updated by segfault 2019-05-27 15:15:26

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 2019-06-01 12:20:32

> 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 2019-06-01 20:29:00

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 2019-06-08 09:17:39

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 (commit: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?