Tails

#1 Updated by sajolida 2017-03-17 19:24:55

• Subject changed from MAC spoofing not disabled to MAC spoofing not disabled in 3.0~beta3

#2 Updated by intrigeri 2017-03-18 07:19:45

• Subject changed from MAC spoofing not disabled in 3.0~beta3 to MAC spoofing cannot be disabled in 3.0~beta3

#3 Updated by sajolida 2017-03-18 09:46:09

• Subject changed from MAC spoofing cannot be disabled in 3.0~beta3 to MAC spoofing cannot be disabled
• Target version changed from Tails_3.0 to Tails_2.12

Actually it’s the same on 2.11 :)

#4 Updated by anonym 2017-04-05 16:45:40

• Status changed from Confirmed to In Progress
• Assignee changed from anonym to sajolida
• % Done changed from 0 to 10
• QA Check set to Info Needed
• Feature Branch set to test/12362-hotplug-vs-mac-spoofing

I couldn’t for the life of me find my physical USB wifi dongle, so I could only test with virtual hardware. I even wrote automated tests, and they cannot reproduce this bug. Can you please retry? This time, please provide the output of macchanger DEV where DEV is the name of the interface device, e.g. eth0, wlan0 whatever.

Meanwhile, let’s see what Jenkins thinks of the MAC address spoofing is disabled scenario for the feature branch.

#5 Updated by sajolida 2017-04-14 15:17:13

• File 12362.pgp added
• Assignee changed from sajolida to anonym
• QA Check changed from Info Needed to Dev Needed

I confirm that the bug is still here in 2.12. I cannot do macchanger DEV because the module for my dongle is removed and the device does not appear in ifconfig. My internal Wi-Fi card does appear with its permanent MAC address. I’m attaching to this ticket a full journalctl from this session, encrypted for you, intrigeri, and me. I hope that’s useful.

#7 Updated by anonym 2017-04-19 17:40:19

• Target version changed from Tails_2.12 to Tails_3.0~rc1

#8 Updated by anonym 2017-04-20 14:28:41

• Subject changed from MAC spoofing cannot be disabled to MAC spoofing cannot be disabled for devices using modules from the staging directory
• Assignee changed from anonym to sajolida
• QA Check changed from Dev Needed to Info Needed

So sajolida’s r8188eu module is in the staging directory (/lib/modules/*/kernel/drivers/staging/) which currently isn’t added to /etc/modprobe.d/all-net-blacklist.conf which explains everything. Looking at config/chroot_local-hooks/80-block-network, which generates that file. Yay, blacklist approaches suck. :)

I don’t see any general solution. The problem that needs to be solved is to tell whether a module is a network device driver or not. I’m afraid the best I can do for now is to add the obvious candidates /lib/modules/*/kernel/drivers/staging/rtl* to the list of directories where we treat all modules as such drivers (which is the case at the moment). This is implemented in the new feature branch (which is based on the old one, so we’ll get the new test, FWIW).

sajolida, would you be willing to test an image once Jenkins has built one?

#9 Updated by sajolida 2017-04-22 10:19:42

• Assignee changed from sajolida to anonym

Yes!

#10 Updated by anonym 2017-04-22 11:02:21

• Assignee changed from anonym to sajolida
• Feature Branch changed from test/12362-hotplug-vs-mac-spoofing to bugfix/12362-mac-spoofing-vs-staging-drivers

Seems I messed up pushing the new branch, so I’ll monitor if it actually builds and seems to create the intended blacklist before asking you to test it. BTW, IIRC you do not like running ISOs from jenkins; do you want me to build + sign and upload an image somewhere?

#12 Updated by sajolida 2017-05-02 12:52:02

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

I tested your ISO and it works as expected, cool!

Still, it made me spot Feature #12500 :(

#13 Updated by intrigeri 2017-05-16 16:49:22

• Assignee changed from anonym to intrigeri
• % Done changed from 10 to 50
• QA Check set to Ready for QA

#14 Updated by intrigeri 2017-05-16 17:14:52

• Assignee changed from intrigeri to anonym
• % Done changed from 50 to 60
• QA Check changed from Ready for QA to Dev Needed

Code review passes, except I’m not 100% convinced by /lib/modules/*/kernel/drivers/staging/rtl*:

• I see /lib/modules/4.9.0-3-amd64/kernel/drivers/staging/wlan-ng/prism2_usb.ko on my system: shouldn’t it be blacklisted too?
• How will we update this list? Maybe add something about it to the release process doc?

#15 Updated by anonym 2017-05-19 16:19:45

• Assignee changed from anonym to intrigeri
• QA Check changed from Dev Needed to Ready for QA

intrigeri wrote:
> Code review passes, except I’m not 100% convinced by /lib/modules/*/kernel/drivers/staging/rtl*:
>
> * I see /lib/modules/4.9.0-3-amd64/kernel/drivers/staging/wlan-ng/prism2_usb.ko on my system: shouldn’t it be blacklisted too?

And vt6656/vt6656_stage.ko.

> * How will we update this list? Maybe add something about it to the release process doc?

Urgh. I really don’t want this if it can be avoided so I implemented an automatic approach, and documented its (reasonable for this context, IMHO) shortcomings. What do you think?

It can easily be tested on your own system by changing the path of the blacklist in the script to something writable. This way you can compare and diff, and you should get something like:

@@ -255,6 +255,7 @@
 install pppox /bin/true
 install ppp_synctty /bin/true
 install pptp /bin/true
+install prism2_usb /bin/true
 install qed /bin/true
 install qede /bin/true
 install qla3xxx /bin/true
@@ -265,6 +266,11 @@
 install r6040 /bin/true
 install r8152 /bin/true
 install r8169 /bin/true
+install r8188eu /bin/true
+install r8192e_pci /bin/true
+install r8192u_usb /bin/true
+install r8712u /bin/true
+install r8723au /bin/true
 install ray_cs /bin/true
 install realtek /bin/true
 install rfc1051 /bin/true
@@ -302,6 +308,10 @@
 install rtl8723-common /bin/true
 install rtl8821ae /bin/true
 install rtl8xxxu /bin/true
+install rtllib /bin/true
+install rtllib_crypt_ccmp /bin/true
+install rtllib_crypt_tkip /bin/true
+install rtllib_crypt_wep /bin/true
 install rtl_pci /bin/true
 install rtl_usb /bin/true
 install rtlwifi /bin/true
@@ -368,6 +378,7 @@
 install vlsi_ir /bin/true
 install vmxnet3 /bin/true
 install vrf /bin/true
+install vt6656_stage /bin/true
 install vxge /bin/true
 install vxlan /bin/true
 install w83977af_ir /bin/true

which, AFAICT, is exactly the diff we want.

#16 Updated by intrigeri 2017-05-19 17:27:31

• Assignee changed from intrigeri to anonym

> Urgh. I really don’t want this if it can be avoided so I implemented an automatic approach, and documented its (reasonable for this context, IMHO) shortcomings.
> What do you think?

I like the idea a lot! I was no big fan of some aspects of the implementation (yeah, nitpicking forever…) so I’ve pushed some refactoring. The resulting script generates the exact same file on my system. Feel free to merge into feature/stretch yourself if you like it :)

#17 Updated by anonym 2017-05-19 19:15:46

• Status changed from In Progress to Resolved
• Assignee deleted (anonym)
• % Done changed from 60 to 100
• QA Check changed from Ready for QA to Pass

Woo, I really like those refactorings! Merged (+ a tiny simplification with commit:98658a8 that intigeri ACKed off-band)!

#18 Updated by anonym 2017-05-19 19:19:16

• Status changed from Resolved to Fix committed

#19 Updated by intrigeri 2017-05-23 09:12:21

• Status changed from Fix committed to Resolved