Improve flawed MAC randomization implementation

[grandbronze111]

I'm using the mailing list as I can't use GitHub with Tor Browser.

This mailing list post is a succinct version of my forum thread https://forum.qubes-os.org/t/mac-randomization-is-flawed-proposed-new-solution/32150

https://github.com/QubesOS/qubes-issues/issues/938 needs to be reopened.

We can’t rely solely on either udev (Tails approach) or NetworkManager (Qubes approach) to ensure the true MAC address is never leaked. Some drivers restore to the true/permanent MAC on sleep/suspend and udev doesn't handle this. NM, in normal operation, brings the NIC 'up' with the true MAC address which can result in leaks. NM also restores to the true MAC address in other cases, such as when the user restarts the NM service to apply an updated config. Even if NM did do everything properly, drivers can still leak the true MAC address.

As originally proposed in /issues/938, patching drivers is the only way to do this without the possibility of leaks occurring. Patching these drivers is usually very simple, as most of them already support generating random MACs for situations where the EEPROM MAC is invalid.

As an initial proposal, I suggest Qubes hosts a contrib repository where these patches can be submitted. Then, Qubes can build a separate kernel with these modified drivers that users can optionally set for their NetVM. I can do the necessary work, but I would want Qubes to confirm how they would like this structured so that it will be accepted. I have built a modified kernel locally with qubesbuilderv2, but I'm not familiar enough with Qubes' build system to say for certain what the best way to do all of this is. It may be that there's an entirely different way to supply the modified drivers that makes more sense than building a separate kernel.

I have said I will patch the 3 most popular wireless drivers to start this off.

There's a lot of additional information in the forum thread so reading everything there is advised.

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Thu, Feb 13, 2025 at 10:09:21PM +0000, 'grandbronze111' via qubes-devel wrote:
> I'm using the mailing list as I can't use GitHub with Tor Browser.
>
> This mailing list post is a succinct version of my forum thread https://forum.qubes-os.org/t/mac-randomization-is-flawed-proposed-new-solution/32150
>
> https://github.com/QubesOS/qubes-issues/issues/938 needs to be reopened.
>
> We can’t rely solely on either udev (Tails approach) or NetworkManager (Qubes approach) to ensure the true MAC address is never leaked. Some drivers restore to the true/permanent MAC on sleep/suspend and udev doesn't handle this. NM, in normal operation, brings the NIC 'up' with the true MAC address which can result in leaks. NM also restores to the true MAC address in other cases, such as when the user restarts the NM service to apply an updated config. Even if NM did do everything properly, drivers can still leak the true MAC address.

Device gets re-initialized after suspend, and NM does re-apply its
configuration on resume, including relevant MAC randomization setting.
_If_ that doesn't work (the above looks like just speculation, not actual
observed behavior), then relevant piece may need fixing. But none of
those pieces are qubes-specific. If setting MAC is broken either in some
specific driver or in Network Manager, then it needs to be reported in
appropriate place (the driver maintainers or NetworkManager bug
tracker).

> As originally proposed in /issues/938, patching drivers is the only way to do this without the possibility of leaks occurring. Patching these drivers is usually very simple, as most of them already support generating random MACs for situations where the EEPROM MAC is invalid.

If driver maintainers would accept such patch, then maybe. We are not
going to carry such patch ourselves.

> As an initial proposal, I suggest Qubes hosts a contrib repository where these patches can be submitted. Then, Qubes can build a separate kernel with these modified drivers that users can optionally set for their NetVM. I can do the necessary work, but I would want Qubes to confirm how they would like this structured so that it will be accepted. I have built a modified kernel locally with qubesbuilderv2, but I'm not familiar enough with Qubes' build system to say for certain what the best way to do all of this is. It may be that there's an entirely different way to supply the modified drivers that makes more sense than building a separate kernel.

See https://docs.kernel.org/process/submitting-patches.html how to
submit Linux patches.

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmevI8oACgkQ24/THMrX
1yyJawf+K7IGlmRzuulRDIiCVtqGjnvj8E3/BsYrqPYruchmFS5JF/Lbj4eqHNHR
CNLpRLrShWgATu9/4GABAUTBInIohP6d0CK4WiCtLxZyJyjpEr879k324TyiXPf5
c42GQ8HzKItagUYY7d+T7TO+J2PTVGVAoAnT8VQtDMUK+/9B3G6oQGsqtSCi3Wm3
imz5MvTPmnTeJErUCyvKITN/TX9WEum0+On9H1SvypjbLqpxBjTmBj2ybP65wr/d
+jyPg6LYznSd+4jciRv7AqhA63DT85EydqMSsfZVDPJTJOYwzJ9CCcMC8IpVs+0S
bns0MvlGCgfF7tESpPeaAxzZ7WCrxQ==
=8Rfy
-----END PGP SIGNATURE-----