Project

General

Profile

Bug #10160

MAC spoofing panic mode is broken

Added by anonym over 4 years ago. Updated over 4 years ago.

Status:
Resolved
Priority:
Elevated
Assignee:
-
Category:
Spoof MAC
Target version:
Start date:
09/03/2015
Due date:
% Done:

100%

Feature Branch:
bugfix/10160-mac-spoofing-panic
Type of work:
Code
Blueprint:
Starter:
Affected tool:

Description

It's really stupid. Look at config/chroot_local-includes/usr/local/sbin/tails-unblock-network. It will wait for config/chroot_local-includes/usr/local/sbin/tails-spoof-mac (via the udevadm settle) to do its thing. If the thing is panic mode, i.e. to stop NetworkManager, well tails-unblock-network will start NetworkManager any way.

In other words, if MAC spoofing is enabled, and for whatever reason some NIC cannot be spoofed and its module cannot be unloaded, then the MAC spoofing panic mode is broken => the error notification will be shown but networking will be enabled from the failing device.

(For the record, I discovered this while working on #6302. Automated testing (or testing at all) FTW :))


Related issues

Blocks Tails - Feature #6302: Write MAC spoofing tests Resolved 09/26/2013

Associated revisions

Revision 5f492526 (diff)
Added by anonym over 4 years ago

Fix a corner case for the MAC spoofing panic mode.

If panic mode failed to disable the specific device that couldn't be
spoofed (by unloading the module) we disable networking. Previously we
only stopped NetworkManager. The problem is that NM isn't even started
at this time, but will specifically be started when we're done with
MAC spoofing.

Therefore, let's remove NetworkManager so it cannot possibly be
started.

Will-fix: #10160

Revision 659aedeb
Added by bertagaz over 4 years ago

Merge branch 'bugfix/10160-mac-spoofing-panic' into stable

Fix-committed: #10160

History

#1 Updated by anonym over 4 years ago

  • Status changed from Confirmed to In Progress

#2 Updated by anonym over 4 years ago

  • Assignee deleted (anonym)
  • % Done changed from 0 to 50
  • QA Check set to Ready for QA

#3 Updated by anonym over 4 years ago

#4 Updated by anonym over 4 years ago

  • Feature Branch set to bugfix/10160-mac-spoofing-panic

#5 Updated by bertagaz over 4 years ago

  • Assignee set to bertagaz

#6 Updated by bertagaz over 4 years ago

  • Assignee changed from bertagaz to anonym
  • % Done changed from 50 to 60
  • QA Check changed from Ready for QA to Info Needed

Tested it with the mac spoofing feature implemented in the test/6302-mac-spoofing with and without an ISO containing this patch.

This bugfix perfectly makes sense to me. Nice to see the automated test suite found an issue! :)

I'd be ready to merge it, but I have one remark: in disable_network() in the config/chroot_local-includes/usr/local/sbin/tails-spoof-mac why not mv the network manager files to something like .disabled files rather than deleting them? This way people could still put them back if they have set the sudo password to go on with the session. I wonder if implementing this idea would require to document it though. Maybe if you agree our Documentation Master (sajolida) could give a hint about that.

#7 Updated by anonym over 4 years ago

  • Assignee changed from anonym to bertagaz
  • QA Check changed from Info Needed to Ready for QA

bertagaz wrote:

Tested it with the mac spoofing feature implemented in the test/6302-mac-spoofing with and without an ISO containing this patch.

This bugfix perfectly makes sense to me.

\o/

Nice to see the automated test suite found an issue! :)

Isn't it? :)

I'd be ready to merge it, but I have one remark: in disable_network() in the config/chroot_local-includes/usr/local/sbin/tails-spoof-mac why not mv the network manager files to something like .disabled files rather than deleting them?

Sure, why not. Done in commit 5a74f29.

This way people could still put them back if they have set the sudo password to go on with the session. I wonder if implementing this idea would require to document it though. Maybe if you agree our Documentation Master (sajolida) could give a hint about that.

This I'm a bit less sure about. The way we've been thinking about the MAC spoofing feature so far has been: "if MAC spoofing fails catastrophically but you absolutely need networking, then reboot and disable that feature, but read the docs first to understand the consequences of leaking the MAC address". Documenting this will just make those docs even longer. Let's not do this.

#8 Updated by bertagaz over 4 years ago

  • Status changed from In Progress to 11
  • % Done changed from 60 to 100

#9 Updated by bertagaz over 4 years ago

  • Assignee deleted (bertagaz)
  • QA Check changed from Ready for QA to Pass

anonym wrote:

bertagaz wrote:

I'd be ready to merge it, but I have one remark: in disable_network() in the config/chroot_local-includes/usr/local/sbin/tails-spoof-mac why not mv the network manager files to something like .disabled files rather than deleting them?

Sure, why not. Done in commit 5a74f29.

Nice sounds ok to me. Didn't test again the whole branch but just that last commit and it seems to work well, so merged in stable!

This way people could still put them back if they have set the sudo password to go on with the session. I wonder if implementing this idea would require to document it though. Maybe if you agree our Documentation Master (sajolida) could give a hint about that.

This I'm a bit less sure about. The way we've been thinking about the MAC spoofing feature so far has been: "if MAC spoofing fails catastrophically but you absolutely need networking, then reboot and disable that feature, but read the docs first to understand the consequences of leaking the MAC address". Documenting this will just make those docs even longer. Let's not do this.

Ack, agree it may not need to bloat the documentation more than that. Let's keep that as a hidden feature. ;)

#10 Updated by bertagaz over 4 years ago

  • Status changed from 11 to Resolved
  • QA Check deleted (Pass)

Also available in: Atom PDF