Anonymizing your MAC Address with macchanger and scripts

[KlausD...@mail2tor.com]

Hey guys,

i have a big problem with "Anonymizing your MAC Address with macchanger
and scripts". I used this Tutorial on the Qubes Doc:
https://www.qubes-os.org/doc/anonymizing-your-mac-address/

Everytime it happens the same:

1) I create the file macspoof@.service with sudo gedit
/etc/systemd/system/macspoof@.service


2) I copie the text in the newly created gedit file:

[Unit]
Description=macchanger on %I
# Hack since macspoof@%i contains @ which is not allowed yet
ConditionPathExists=/var/run/qubes-service/macspoof-%i
Wants=network-pre.target
Before=network-pre.target
BindsTo=sys-subsystem-net-devices-%i.device
After=sys-subsystem-net-devices-%i.device

[Service]
ExecStart=/usr/bin/macchanger -e %I
Type=oneshot

[Install]
WantedBy=multi-user.target


3) In the Fedora Terminal is says:

[user@fedora-23 ~]$ sudo gedit /etc/systemd/system/macspoof@.service

(gedit:1029): Gtk-WARNING **: Calling Inhibit failed:
GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name
org.gnome.SessionManager was not provided by any .service files

What should i do?

[Yuraeitha]

It could be that you're using fedora 23? It's no longer supported, and maybe it's unable of talking with the rest of your Qubes system in a proper way, thus perhaps that is why it fails for you. Are you sure you keep dom0/templates updated in sync with each others? For example your dom0 may be updated, but your fedora-23 template isn't since its no longer maintained.

Fedora 24/25 is no good either, you need to go all the way to fedora-26. Fedora 27 is out too, but it's not fully supported by Qubes yet. So fedora-26 is what you want. You can download and install it with "sudo qubes-dom0-update qubes-template-fedora-26" <--- it will take a while, especially if you got a slow connection or system. Be sure you got plenty of gigabyte space ready for it to install on, it'll take a bit more space to install before it shrinks again when finished.

Update the template fully, and try perform your script in the fedora-26 template instead.

Also be sure you change your sys-net and sys-firewall, and other VM's that run on out of date and no longer supported templates. You need to fully change all of them away from fedora-23, before you can delete the old fedora-23 as well.

[Chris Laprise]

On 02/28/2018 11:31 AM, KlausD...@mail2tor.com wrote:
> Hey guys,
>
> i have a big problem with "Anonymizing your MAC Address with macchanger
> and scripts". I used this Tutorial on the Qubes Doc:
> https://www.qubes-os.org/doc/anonymizing-your-mac-address/

Hi,

The macchanger section of the doc hasn't worked for a long time (search
the mailing list to see issues) and it never did work correctly, IMO.

> What should i do?
>

You should use the MAC randomization feature integrated into Network
Manager, shown at the beginning of the doc.

--

Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

[awokd]

On Wed, February 28, 2018 6:34 pm, Chris Laprise wrote:
> On 02/28/2018 11:31 AM, KlausD...@mail2tor.com wrote:
>
>> Hey guys,
>>
>>
>> i have a big problem with "Anonymizing your MAC Address with macchanger
>> and scripts". I used this Tutorial on the Qubes Doc:
>> https://www.qubes-os.org/doc/anonymizing-your-mac-address/
>>
>
> Hi,
>
>
> The macchanger section of the doc hasn't worked for a long time (search
> the mailing list to see issues) and it never did work correctly, IMO.
>

Should it be deleted? I can put in a PR, but that won't leave much left on
that doc. Should what's left work on R4.0?

[Chris Laprise]

That section has been defunct/abandoned for almost 2 years, so yeah it
should be deleted. I know initially a lot of work went into it, but then
interest quickly dropped off probably because the scripted approach
wasn't practical for that task.

[Chris Laprise]

On 02/28/2018 01:49 PM, awokd wrote:

To answer your other question: Yes, the NM instructions work equally
well under 3.2 and 4.0.

There's not much verbiage but that is often a good thing. I can expand
it a bit by showing an additional NM config that generates a random MAC
only once and retains it for each wifi access point.

[vel...@tutamail.com]

Chris if you could replicate the simplicity in your instruction for a "kill-switc-VPN" for the this feature that would be awesome...

This seems like a great feature...I am getting up to speed on the Linux commands but I suspect a lot of the laypeople(who likely need the security) would appreciate this feature if they could understand the detailed steps, even if simple.

Thanks again for all you do....

V

https://groups.google.com/forum/#!searchin/qubes-users/vpn$20github%7Csort:date/qubes-users/FUQaRPWXPj8/SMlPfhwuAgAJ

[Yuraeitha]

To add to your thoughts V, maybe this could even be implemented it in Qubes directly, with a simple turn on/off switch or command? It seems like this would be helpful for new users seeking Qubes for privacy concerns. I know Qubes is primary focused on security, but it'd be a one step closer to make Qubes easy to use for people not into the terminal/how-to guides. It would also make it easier when upgrading a new Qubes, for example when Qubes 4.1. and Qubes 5 is out, and guides once again face questions as to if they work on a Qubes version or not (all over again).

What do you think Chris? is this realistic, feasible in terms of no newly introduces downsides, or even desired?

[bill...@gmail.com]

On Wednesday, February 28, 2018 at 1:34:28 PM UTC-5, Chris Laprise wrote:

> Hi,
>
> The macchanger section of the doc hasn't worked for a long time (search
> the mailing list to see issues) and it never did work correctly, IMO.
>
> > What should i do?
> >
>
> You should use the MAC randomization feature integrated into Network
> Manager, shown at the beginning of the doc.
>
> --
>
> Chris Laprise, tas...@posteo.net
> https://github.com/tasket
> https://twitter.com/ttaskett
> PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

This is not qubes-specific. It hasn't worked in fedora for a long time, and I don't think it works in ubuntu/debian either, as long as NetworkManager is turned on. In regular fedora, you can use macchanger if you turn off NetworkManager and manage all your connections yourself, but that's quite a hassle.

The thing I don't like about NetworkManager MAC address randomization compared to macchanger, is that it is connection-specific, not network device-specific, and I prefer the latter.

billo

[awokd]

On Thu, March 1, 2018 1:14 am, bill...@gmail.com wrote:

>
> This is not qubes-specific. It hasn't worked in fedora for a long time,
> and I don't think it works in ubuntu/debian either, as long as
> NetworkManager is turned on. In regular fedora, you can use macchanger
> if you turn off NetworkManager and manage all your connections yourself,
> but that's quite a hassle.
>
> The thing I don't like about NetworkManager MAC address randomization
> compared to macchanger, is that it is connection-specific, not network
> device-specific, and I prefer the latter.

Might be worth keeping the content around then if all we need to do is add
that note about disabling NetworkManager.

[Chris Laprise]

On 02/28/2018 08:23 PM, 'awokd' via qubes-users wrote:
> On Thu, March 1, 2018 1:14 am, bill...@gmail.com wrote:
>
>>
>> This is not qubes-specific. It hasn't worked in fedora for a long time,
>> and I don't think it works in ubuntu/debian either, as long as
>> NetworkManager is turned on. In regular fedora, you can use macchanger
>> if you turn off NetworkManager and manage all your connections yourself,
>> but that's quite a hassle.
>>
>> The thing I don't like about NetworkManager MAC address randomization
>> compared to macchanger, is that it is connection-specific, not network
>> device-specific, and I prefer the latter.

Yes, NM does it that way because the main necessity is to prevent users
being tracked as their machines are moved geographically. (Of course,
the prevention is theoretical at this point because other metadata has
not yet been suppressed.)

>
> Might be worth keeping the content around then if all we need to do is add
> that note about disabling NetworkManager.

Unfortunately, even when they worked the macchanger scripts still had
some big issues with the address reverting back to original when certain
system events occurred. That's why the feature had to be integrated.

There are now three places in Linux where MAC randomization can be
managed properly: WPA Supplicant (I think for wifi only), NM and
systemd. NM seems to provide the best overlap between simplicity and
flexibility. OTOH using macchanger is much more complicated and likely
to leak your hardware address.

[Chris Laprise]

I can't tell if MAC addresses or VPNs are being discussed at this point.
If the latter, then I've already posted the new code and done 90% of the
changes needed to make the doc simpler (essentially 3 steps, not
counting "test the connection" and "restart the VM"). So, we'll see
when/if the new solution gets integrated.

For MAC addresses, I'd actually recommend making randomization the
default _at some point_. But right now the exercise is academic because
firmware and driver vendors haven't addressed the problem of unique
non-address metadata that NICs are also transmitting.

Even though its academic, I'd rather not see people struggle with
macchanger when it could still leak the original address, whether or not
the other metadata is sent.

[Chris Laprise]

On 02/28/2018 08:23 PM, 'awokd' via qubes-users wrote:

> On Thu, March 1, 2018 1:14 am, bill...@gmail.com wrote:
>
>>
>> This is not qubes-specific. It hasn't worked in fedora for a long time,
>> and I don't think it works in ubuntu/debian either, as long as
>> NetworkManager is turned on. In regular fedora, you can use macchanger
>> if you turn off NetworkManager and manage all your connections yourself,
>> but that's quite a hassle.

BTW, as an example of Qubes-specifics in this issue, on sleep/wake
networkVMs don't process the normal array of events and system states
that bare-metal Linux distros do. At least this was the case for 3.x.
The result was that advocates of the macchanger script method (which
relied on such events and related hooks) recommended that users keep a
watch on the current MAC address and restart sys-net whenever it
reverted (waking from sleep was the most common/blatant example). They
didn't care to address the fact that the waking system was already
broadcasting the original address before the user had a chance to
restart sys-net (and not to mention the unmitigated headache of
restarting/reassigning all the dependant VMs).

[bill...@gmail.com]

On Thursday, March 1, 2018 at 12:08:19 AM UTC-5, Chris Laprise wrote:
> On 02/28/2018 08:23 PM, 'awokd' via qubes-users wrote:
>
> BTW, as an example of Qubes-specifics in this issue, on sleep/wake
> networkVMs don't process the normal array of events and system states
> that bare-metal Linux distros do. At least this was the case for 3.x.
> The result was that advocates of the macchanger script method (which
> relied on such events and related hooks) recommended that users keep a
> watch on the current MAC address and restart sys-net whenever it
> reverted (waking from sleep was the most common/blatant example). They
> didn't care to address the fact that the waking system was already
> broadcasting the original address before the user had a chance to
> restart sys-net (and not to mention the unmitigated headache of
> restarting/reassigning all the dependant VMs).
>
>
>

Well, to be honest, I haven't kept up with it once I decided it wasn't going to work. As I remember (and this is back before systemd, and you could still control everything from the /etc/rc<n>.d files very easily), I put a little script in /etc/init.d and did the macchanger thing before I allowed the network to connect to anything. If the network turned off, then it would randomize when it turned on.

I don't remember it reverting, but I may have just not been paying attention (or have forgotten in the haze of time -- it's amazing to me how quickly one forgets little sysadmin tricks when one stops doing it all the time). I never dealt with VMs except for running Windows in Virtualbox, so I am clueless there... ... though I am getting interested again playing with qubes.

[Unman]

The problem with NM method is that it gives you a fully random MAC
which makes you stand out like a sore thumb. Also, with some NICs, it's
easier to drop NM and use something like wicd, so the macchanger
instructions remain useful.

I've used macchanger for years now, without leakage. But then, I'm a
strong advocate of NOT using the network over a sleep/wake cycle. I see
no point in using MAC randomisation if you're spewing out content when
you wake from sleep.

[Chris Laprise]

On 03/02/2018 05:43 AM, Unman wrote:
> On Thu, Mar 01, 2018 at 05:52:48AM -0800, bill...@gmail.com wrote:
>> On Thursday, March 1, 2018 at 12:08:19 AM UTC-5, Chris Laprise wrote:
>>> On 02/28/2018 08:23 PM, 'awokd' via qubes-users wrote:
>>>
>>> BTW, as an example of Qubes-specifics in this issue, on sleep/wake
>>> networkVMs don't process the normal array of events and system states
>>> that bare-metal Linux distros do. At least this was the case for 3.x.
>>> The result was that advocates of the macchanger script method (which
>>> relied on such events and related hooks) recommended that users keep a
>>> watch on the current MAC address and restart sys-net whenever it
>>> reverted (waking from sleep was the most common/blatant example). They
>>> didn't care to address the fact that the waking system was already
>>> broadcasting the original address before the user had a chance to
>>> restart sys-net (and not to mention the unmitigated headache of
>>> restarting/reassigning all the dependant VMs).
>>>
>>>
>>>
>>
>> Well, to be honest, I haven't kept up with it once I decided it wasn't going to work. As I remember (and this is back before systemd, and you could still control everything from the /etc/rc<n>.d files very easily), I put a little script in /etc/init.d and did the macchanger thing before I allowed the network to connect to anything. If the network turned off, then it would randomize when it turned on.
>>
>> I don't remember it reverting, but I may have just not been paying attention (or have forgotten in the haze of time -- it's amazing to me how quickly one forgets little sysadmin tricks when one stops doing it all the time). I never dealt with VMs except for running Windows in Virtualbox, so I am clueless there... ... though I am getting interested again playing with qubes.
>>
>
> The problem with NM method is that it gives you a fully random MAC
> which makes you stand out like a sore thumb. Also, with some NICs, it's
> easier to drop NM and use something like wicd, so the macchanger
> instructions remain useful.

I could be wrong, but I thought the NM default behaved similar to the
randomization range on Android and Windows.

But if its an issue, NM allows you to specify a bitmask to limit the range.