Tails

#4 Updated by intrigeri 2018-01-22 09:24:15

I’ve deleted a few comments that did not add any useful information but clearly violated https://tails.boum.org/contribute/working_together/code_of_conduct/.

#8 Updated by humanrightsdefender 2018-01-24 08:47:51

“If you do this then you are effectively forking that entire directory, so you won’t get any update we need to make in there. It may be unsafe or cause bugs that nobody else can reproduce.”

I’m perfectly fine with the option of “fork” the /etc/NetworkManager/conf.d directory to fully randomize my MAC address!

“so you won’t get any update we need to make in there”

Hmm… You need to update nothing in conf.d!

<code class="text">

#AFTER BOOT
amnesia@amnesia:~$ macchanger wlan0 -s
Current MAC:   86:9e:32:96:53:52 (unknown)
Permanent MAC: 4a:9b:c2:12:69:0c (Intel Corporate)

#CONNECTED TO NETWORK 
amnesia@amnesia:~$ macchanger wlan0 -s
Current MAC:   66:f0:72:32:02:d3 (unknown)
Permanent MAC: 4a:9b:c2:12:69:0c (Intel Corporate)

#DIRECTORY
amnesia@amnesia:~$ ls /etc/NetworkManager
conf.d        dnsmasq.d         NetworkManager.conf  VPN
dispatcher.d  dnsmasq-shared.d  system-connections
amnesia@amnesia:~$ ls /etc/NetworkManager/conf.d
dns.conf  spoof-mac.conf

#CURRENT CONF
amnesia@amnesia:~$ cat /etc/NetworkManager/conf.d/spoof-mac.conf
[device]
wifi.scan-rand-mac-address=yes

[connection]
wifi.cloned-mac-address=stable
ethernet.cloned-mac-address=stable

#SYS
amnesia@amnesia:~$ uname -a
Linux amnesia 4.14.0-3-amd64 #1 SMP Debian 4.14.13-1 (2018-01-14) x86_64 GNU/Linux
amnesia@amnesia:~$ 
</code>

#9 Updated by humanrightsdefender 2018-01-24 09:04:19

“https://tails.boum.org/contribute/design/MAC_address/#limitation-only-spoof-nic-part explains why the solution you’re proposing may introduce worse problems than it solves.”

YOU ARE WRONG! In fact this link explains nothing useful and so is not offering solution. To have a fully random MAC is essential and so this ticket must be reopened since this is the solution!

I would say okay if spoofing MAC implemented on the way that TAILS not exposing the HALF OF THE PERMANENT MAC and the REAL MANUFACTURER for example TAILS can give us a fully random MAC which may display some different manufacturer for it and not (unknown). It’s is extremly dangerious to expose the HALF of the permanent MAC and the original manufacturer!

As above I explained you need to update nothing in conf.d and so the “fork” should be DEFAULT FOR ALL TAILS USERS!

#10 Updated by intrigeri 2018-01-24 09:06:46

> “so you won’t get any update we need to make in there”

> Hmm… You need to update nothing in conf.d!

This will help you check your facts:
https://git-tails.immerda.ch/tails/log/config/chroot_local-includes/etc/NetworkManager/conf.d

#11 Updated by humanrightsdefender 2018-01-24 09:28:35

Ahh you also use integri@immerda.ch ? xD Everyone I know use @immerda.

This part is supporting my claims from https://tails.boum.org/contribute/design/MAC_address/#limitation-only-spoof-nic-part

Wi-Fi scanning

During Wi-Fi access point scanning, NetworkManager randomizes MAC addresses (wifi.scan-rand-mac-address), so the MAC address used for scanning is different from the one later used to connect to a Wi-Fi access point. This makes it slightly harder to correlate scanning activity with actual connections to a Wi-Fi network.

Relating to conf.d the latest is “Configure NetworkManager to not touch MAC addresses”
https://git-tails.immerda.ch/tails/commit/config/chroot_local-includes/etc/NetworkManager/conf.d?id=73e432752beb02127482867eb531faab9d085749

You can still make updates in /etc/NetworkManager/ but you don’t need touch dns.conf and spoof-mac.conf in conf.d directory.

plugins.conf and dhcp-hostname.conf is not in conf.d anymore.. https://git-tails.immerda.ch/tails/commit/config/chroot_local-includes/etc/NetworkManager/conf.d?id=ebac17a6357168be5d9a4c4c15019afa6b8857f7

This is the reason why this ticket should be reopened and pushed with the next update.

#12 Updated by intrigeri 2018-01-24 09:28:38

> In fact this link explains nothing useful and so is not offering solution.

1. Read the entire page.
2. Pay attention to AvoidIdMacSpoof and AdvGoalIdMacSpoof in there.

#13 Updated by humanrightsdefender 2018-01-24 09:34:10

“Its default behaviour on Debian Stretch is to reset the MAC address to the permanent one, and we did not make up our mind yet wrt. replacing our custom MAC spoofing system with NM’s own one (refs: Feature #11293).”

Anything else?

#14 Updated by humanrightsdefender 2018-01-24 09:38:16

There is NO EXCUSE for exposing the half of the permanent MAC address and the real manufacturer! Nothing can justify such thing in TAILS! Amnesia hah? Let’s give fully random and stable option to spoof MAC in TAILS! More secure than let it how it is today. (Not in mine… since as you said I forked and I’m very happy with this result!)

#15 Updated by humanrightsdefender 2018-01-24 09:43:30

<code class="text">
amnesia@amnesia:~$ cat /etc/NetworkManager/conf.d/spoof-mac.conf
[device]
wifi.scan-rand-mac-address=yes

[connection]
wifi.cloned-mac-address=stable
ethernet.cloned-mac-address=stable
</code>

You expose the half of the permanent MAC and manufacturer all the time when you use TAILS and since TAILS forcing TOR those who want to get you can find you fast with seeing the tor traffic all the time from you. They have already the half of your permenent MAC and the real manufacturer in the end even can throw you to jail because after they can say this person that time used tails on that device… and if you using a public network and all the time just the half of your mac changes that is FATAL ERROR!

#16 Updated by humanrightsdefender 2018-01-24 10:05:24

“stable”: generate a stable, hashed MAC address.
https://blogs.gnome.org/thaller/2016/08/26/mac-address-spoofing-in-networkmanager-1-4-0/

Qubes OS has exactly the same spoofing implemented https://www.qubes-os.org/doc/anonymizing-your-mac-address/

#17 Updated by humanrightsdefender 2018-01-24 10:07:05

Not implemented but recommended.

#18 Updated by humanrightsdefender 2018-01-24 10:16:11

<code class="text">
The “stable” method warrants more explanation. In a way it is similar to “random”, but instead it generates a stable, hashed value. This way every time the connection activates, the same address is generated. However, each connection generates a different address.

This is for example useful so that you get the same IP address from DHCP, which might not be the case with “random”. Or a captive-portal might remember your login-status based on the MAC address. With “random” you may be required to re-authenticate on every connect.

The “stable” mode still makes you easily recognizable when you re-connect to a previous network, but your hardware MAC address is hidden and tracking you across different networks may be harder (YMMV).

The stable address is generated by hashing a private key from /var/lib/NetworkManager/secret_key, the ifname of the device, and a stable-id. The stable-id by default is the UUID of the connection (“connection.uuid”), unless you configure the new property “connection.stable-id“. The latter allows you to have multiple connections that generate the same MAC address. Note that “connection.stable-id” property is also used when generating stable-privacy IPv6 addresses (“ipv6.addr-gen-mode”, RFC 7217).
</code>

#19 Updated by humanrightsdefender 2018-01-24 10:16:43

The “stable” method warrants more explanation. In a way it is similar to “random”, but instead it generates a stable, hashed value. This way every time the connection activates, the same address is generated. However, each connection generates a different address.

This is for example useful so that you get the same IP address from DHCP, which might not be the case with “random”. Or a captive-portal might remember your login-status based on the MAC address. With “random” you may be required to re-authenticate on every connect.

The “stable” mode still makes you easily recognizable when you re-connect to a previous network, but your hardware MAC address is hidden and tracking you across different networks may be harder (YMMV).

The stable address is generated by hashing a private key from /var/lib/NetworkManager/secret_key, the ifname of the device, and a stable-id. The stable-id by default is the UUID of the connection (“connection.uuid”), unless you configure the new property “connection.stable-id“. The latter allows you to have multiple connections that generate the same MAC address. Note that “connection.stable-id” property is also used when generating stable-privacy IPv6 addresses (“ipv6.addr-gen-mode”, RFC 7217).

#20 Updated by humanrightsdefender 2018-01-24 10:20:40

In TAILS this works perfectly and each reboot gives one fully random MAC until you connect to the Network (that step is the stable) meaning that if you disconnect you will again get a new mac but when you reconnect will give you agains the same stable spoofed MAC. Way more secure the the actual TAILS implementation.

#21 Updated by humanrightsdefender 2018-01-24 10:24:24

the actual tails conf when you reconnect again change the HALF of your permanent mac address and so you are more likely to be targeted. If tor disconnects for some reason than you NEED to reconnect and so the network admin will see that you have changed your MAC but NOT FULLY which eventually helps him and hi can call police immediatelly since they will have everything to put you in Jail. Half of the permanent MAC and manufacturer. Can you imagine this in library? Tails with the current setup is dangerious!

#22 Updated by humanrightsdefender 2018-01-24 10:26:43

The “stable” mode still makes you easily recognizable when you re-connect to a previous network, but your hardware MAC address is hidden and tracking you across different networks may be harder (YMMV).

#23 Updated by humanrightsdefender 2018-01-24 10:30:06

Please reopen the ticket and push a security update!

#24 Updated by humanrightsdefender 2018-01-24 10:47:23

ETH0 is NOT spoofed at all in TAILS! I’m looking into this now.

#25 Updated by humanrightsdefender 2018-01-24 10:49:44

Yes, ETH0 spoofed exactly the same way! Exposing the hal and the real manufacturer. This is not okay! Now I need to solve this also?

#26 Updated by humanrightsdefender 2018-01-24 11:04:26

I test now with editing *sudo crontab -e

• and adding this:

<code class="text">
@reboot macchanger -r eth0
@reboot macchanger -r wlan0
</code>