Feature #8328

Check if tails-restricted-network-detector still works on Jessie

Added by intrigeri 2014-11-27 21:59:23 . Updated 2015-11-17 07:36:02 .

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Spoof MAC
Target version:
Start date:
2014-11-27
Due date:
% Done:

100%

Feature Branch:
Type of work:
Test
Blueprint:

Starter:
Affected tool:
Deliverable for:

Description

It’s grepping logs for specific strings, that might have changed in Jessie (and possibly even in Wheezy? not sure we’ve ever checked that.)


Files


Subtasks


Related issues

Related to Tails - Bug #10560: Reintroduce tails-restricted-network-detector Rejected 2015-11-17

History

#1 Updated by romeopapa 2015-08-11 17:16:59

Summary:

Basically, I believe it is broken in jessie and stable!! Included a patch.

I’ve inspected NetworkManager’s code, at version 0.9.10.0 (the current one used in feature/jessie) and 0.9.4 (used on stable), I’ve found the following:

/Activation \(([^)]+)\) starting connection/:

Yes, the code that outputs this string is still there.
Warning: it seems to have changed at v1.0.4, which is currently on debian sid

/\(([^)]+)\): supplicant connection state:.-> (.)$/:

This has changed!

I believe I have found the replacements:
src/devices/wifi/nm-device-wifi.c:2198:

nm_log_info (LOGD_DEVICE | LOGD_WIFI,
                 "(%s): supplicant interface state: %s -> %s",
                 nm_device_get_iface (device),
                 nm_supplicant_interface_state_to_string (old_state),
                 nm_supplicant_interface_state_to_string (new_state));


src/devices/nm-device-ethernet.c:705:

nm_log_info (LOGD_DEVICE | LOGD_ETHER,
                 "(%s): supplicant interface state: %s -> %s",
                 nm_device_get_iface (device),
                 nm_supplicant_interface_state_to_string (old_state),
                 nm_supplicant_interface_state_to_string (new_state));

nm_supplicant_interface_state_to_string (guint32 state) seems to be spitting out the word ‘associating’ correctly.

Seems good on v1.0.4 too.

/Activation \(([^)]+)\/[^)]*\): association took too long/

Yes, the code that outputs this string is still there.

Seems good on v1.0.4 too.

Here’s the commit:
https://gitlab.com/romeopapa/tails/commits/bugfix/8328-check-if-tails-restricted-network-detector-still-works-on-jessie

#2 Updated by intrigeri 2015-08-18 05:36:12

  • QA Check set to Info Needed

> Basically, I believe it is broken in jessie and stable!! Included a patch.

Ouch. Thanks for checking. Did you test the brokenness and/or the fix on Tails 1.5 and/or Jessie?
Or did you only look at the source code?

#3 Updated by anonym 2015-10-21 07:33:35

  • Assignee changed from anonym to romeopapa

intrigeri wrote:
> > Basically, I believe it is broken in jessie and stable!! Included a patch.
>
> Ouch. Thanks for checking. Did you test the brokenness and/or the fix on Tails 1.5 and/or Jessie?
> Or did you only look at the source code?

I believe this question was directed not to me, but the reporter.

It seems I discovered this independently and solved it in Bug #7689 via commit commit:579f2d8.

#4 Updated by intrigeri 2015-11-10 11:10:08

  • Assignee changed from romeopapa to anonym
  • QA Check deleted (Info Needed)

Can you please take care of this one? Given you just fixed it on Wheezy, and it’s your area, I figure it’s easier for you than for me to “quickly” test it. If it’s not, then please reassign to me.

#5 Updated by intrigeri 2015-11-12 09:00:25

  • Status changed from Confirmed to In Progress
  • % Done changed from 0 to 50
  • QA Check set to Info Needed

I gave it a try and implemented MAC address whitelist-based filtering on my home router.

  • Tails 1.7 (Wheezy): I see no notification; in the logs I see the “took too long” message, but the state was “authenticating”, while the code expects “associating”, so it looks like the detector has been broken since we switched to Wheezy;
  • feature/jessie: as soon as the kernel reports “wlan0: xx:xx:xx:xx:xx:xx denied authentication (status 1)”, NM switches to “disconnected” state. So the logic on which the detector is based cannot work anymore. And then of course I see no notification.

I’m tempted to simply drop the detector in feature/jessie (it’s been broken for 16 months and nobody complained AFAIK), and to create a ticket about reintroducing+fixing it (that would be a feature request, and would not block 2.0, since it’s not a regression introduced by the upgrade to Jessie, technically / ǜber-formally speaking). IMO, even fixing the detector in current stable/devel seems like a waste of our time given the above facts.

anonym, what do you think?

#6 Updated by intrigeri 2015-11-17 06:36:29

  • related to Bug #10560: Reintroduce tails-restricted-network-detector added

#7 Updated by intrigeri 2015-11-17 06:37:38

  • Assignee changed from anonym to intrigeri
  • QA Check deleted (Info Needed)

intrigeri wrote:
> I’m tempted to simply drop the detector in feature/jessie (it’s been broken for 16 months and nobody complained AFAIK), and to create a ticket about reintroducing+fixing it (that would be a feature request, and would not block 2.0, since it’s not a regression introduced by the upgrade to Jessie, technically / ǜber-formally speaking).

I’ve discussed this privately with sajolida, who agrees with my take on it. I’ve created Bug #10560 and will drop the detector from feature/jessie.

#8 Updated by intrigeri 2015-11-17 07:34:56

  • Status changed from In Progress to Resolved
  • % Done changed from 50 to 100

Applied in changeset commit:16b3d9dc22ef67cd2fcf8527307823281c0e753d.

#9 Updated by intrigeri 2015-11-17 07:36:02

  • Assignee deleted (intrigeri)