That is the one to focus on. If you could contribute that, it would be helpful. Upstream already gave a green light on its usefulness and said, “patches welcome.”
I looked into this and I could implement it, but it only improves the situation and doesn’t make it “surefire”. From my original post:
They could change the code to not do this, but even if they make the change I would be hesitant to rely on NetworkManager for the purpose of MAC randomization. NM is a large and complex codebase, which does not put privacy first. Modifying the drivers, although tedious due to the large number of drivers, actually allows us to very easily verify that the MAC is not leaking due to the simplicity of the code that reads EEPROM and sets the permanent MAC.
My recommendation: Contribute a few small patches upstream on unrelated but helpful topics that require little or no support. Having a track record of successfully merged patches, regardless of the specific Open Source project, can build trust and increase the chances of extended support during your more significant contributions later.
I’ve contributed to Qubes, Whonix and Tor Browser before. I use these daily and always try to improve them for myself and others. I don’t like to create a linked history of all my work as that could result in me being a target.
I don’t know if Qubes is willing to carry kernel driver patches, even if contributed. This is because the kernel changes over time, Qubes needs to rebase to newer kernel versions, and updating the patches might require ongoing maintenance effort. You need to ask Qubes.
My recommendation was to put these into a Qubes contrib package, which is community maintained. It would be up to the community to modify the drivers as the kernel is updated. I intend to keep the drivers I use up to date for as long as I use Qubes, which is likely “forever”. I’ve also informed Tails that their current solution has issues and that they can’t rely on NM either, so it’s possible they will get involved with driver modifications at some stage. The thing is, most drivers assume that the MAC address stored in EEPROM may be invalid, and they have a path to randomly generate it in this case. So the modifications are usually as simple as forcing this path every time, which only requires changing one or two lines of code.
Needless to say, if such patches were merged upstream in Linux, that would avoid the patch rebase issue but may be even more difficult.
Can’t see it happening.
MAC randomization is a difficult topic. [2] [3] [4] [5] Implementations using NetworkManager and/or udev might, in theory, leak the original MAC address. This is because these are complex code bases with complex system interactions, where MAC randomization was not supported at the founding of these projects but bolted on later as an afterthought. Supporting MAC randomization at a different level, such as by the kernel, might be a more reliable approach to MAC randomization.
Thanks, this is really appreciated.
Could you clarify which specific flaw you’re referring to?
I was referring to the flaw which is that the MAC address can still leak despite NetworkManager being configured with randomization.
Since you wanted to contribute, editing the wiki is one way.
I will add everything to the Whonix wiki once I know whether we will get support from Qubes. If Qubes does not give us support I will post the instructions for compiling the modified kernel locally, but this is a really bad way to do it for multiple reasons.