search

QubesOS / qubes-issues

The Qubes OS Project issue tracker
https://www.qubes-os.org/doc/issue-tracking/
532 stars 46 forks source link

MAC Randomization for iwlwifi #938

Closed marmarek closed 6 years ago

marmarek commented 9 years ago

Reported by andrewb on 6 Dec 2014 03:15 UTC See https://groups.google.com/d/msg/qubes-users/Yo73MZC4038/a5ONmKpLB5YJ -- qubes-users subject "MAC randomization experiments": On 07/17/14 13:51, Joanna Rutkowska wrote:

On 07/09/14 14:36, cprise wrote:

As a follow-up to the 'random MAC addresses (wifi)' thread, I was wondering if anyone has tried automating it on Qubes and if so, what some of your experiences are.

I have started trying out different approaches, but it appears that the hooks/interfaces needed at this level are undergoing a great deal of flux, and the fact of having wifi live in a vm throws a wrinkle or two in there as well.

My underlying rule is: Since bootup /and/ resume both reset the address to the hardware ID, randomization must be handled during those events to prevent the wifi interface from becoming active with and broadcasting the hardware ID. Handling the bootup part is easy; Suspend is a whole other story.

The NICs I played with some years ago, specifically Intel AGN WiFi, used to relay on the driver code to set the MAC address on device initialization. The code looked more or less like this (quoting from memory):

my_nc_mac = read_eeprom (eeprom_address_mac); set_hw_mac_address (my_nic_mac);

This means the h/w itself doesn't know the MAC apriori (i.e it's not burned into the chip), but expects the driver to tell it what the mac should be.

Patching the driver code above should be the most sure way to change the mac address and ensure the NIC never ever use the original mac.

joanna.

Since iwlwifi devices are so popular with the business-class systems that seem to work well with Qubes, it makes sense to adopt this "surefire" MAC randomization strategy. Most people who want Qubes probably also want MAC randomization. Unless there's a more general solution, let's adopt this idea.

How much effort would it take to maintain this patch for iwlwifi? Has someone else done it already?

Migrated-From: https://wiki.qubes-os.org/ticket/938

mfc commented 8 years ago

folks this is a very important feature for anonymity/privacy purposes, adding @adrelanos. There are a number of tools to help implement this, I don't think we need to maintain a patch for iwlwifi:

https://directory.fsf.org/wiki/GNU_MAC_Changer https://github.com/subgraph/macouflage

adrelanos commented 8 years ago

The workable, sane solution would be "all big Linux distributions should always randomize the MAC", which fails for political reasons.

Solving this in Tails, Whonix or Qubes is very difficult UX wise (@bnvk) and backend implementation wise.

Points to more information:

https://github.com/subgraph/macouflage

Requires review. If they are aware of Tails' research and acted accordingly or chose to ignore Tails' research. That includes issues with using the data set gathered by macchiato.

mfc commented 8 years ago

Thanks for linking to the Tails research, and mentioning macchiato. I agree that the Tails research is probably the most robust think-through out there.

Their current strategy is to have MAC spoofing on by default, and disable-able in the Tails Greeter when first booting if desired.

I find this a very reasonable approach, and think it could be a setting in the whonix-gateway, on by default but disable-able (via GUI) if desired.

This is for users who are using the whonix-gateway, so they are already interested in anonymity and privacy. Having MAC spoofing makes perfect sense for them (hence the mailing-list thread on it). Trying to connect to Tor also sometimes breaks things (like a captive portal for example), so if they are unable to connect to the internet the error message that currently exists for not successfully connecting to Tor could mention the MAC spoofing and disabling it if desired.

marmarek commented 8 years ago

On Sun, Oct 04, 2015 at 02:42:29PM -0700, Michael Carbone wrote:

I find this a very reasonable approach, and think it could be a setting in the whonix-gateway, on by default but disable-able (via GUI) if desired.

Whonix-gateway (and more importantly whonix-workstation) does not have access to the network adapter, so this is much less concern in Qubes.

But still sometimes useful option. IMHO it would be the best if possible to set on (wifi) connection basis. Not sure if technically possible (for example somehow needs to scan for available networks). Maybe someone have already implemented such thing (NetworkManager plugin?)?

Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing?

mfc commented 8 years ago

Whonix-gateway (and more importantly whonix-workstation) does not have access to the network adapter, so this is much less concern in Qubes.

ah apologies thanks for clarifying this would need to be implemented in netvm.

adrelanos commented 8 years ago

this would need to be implemented in netvm

It's related to netvm, yes. It's still related to anonymity, though.

So I am wondering,

There is no network manager plugin. Only the Tails custom implementation which is non-trivial.

When the user should be given the possibility to enable/disable MAC changing?

marmarek commented 8 years ago

On Mon, Oct 05, 2015 at 12:25:47AM -0700, Patrick Schleizer wrote:

  • 1) if this feature could be implemented in whonix-setup-wizard. + A qrexec service so Whonix-Gateway can signal to netvm what to do about MAC spoofing.
  • 2) Or if rather Whonix-Gateway should be capable to work as netvm. Might be easier to make Whonix-Gateway work as netvm than having Whonix-Gateway and netvm cooperate. (I am not specifically eager to receive all the hardware support questions.)

I think it should be possible to use this feature even without Whonix, so none of above.

There is no network manager plugin. Only the Tails custom implementation which is non-trivial.

  • don't actively scan the network before the user decided what to do about MAC spoofing
  • change MAC before touching the network
  • detect if new wifi hardware is attached, make sure MAC is changed before it tries to connect

Can you point the code/implementation details? Can we reuse some of this? If not, I think it worth evaluate NetworkManager plugin API - this way we may be able to do all the about without fearing some race condition, because it's NetworkManager who enables and configures the network interface.

When the user should be given the possibility to enable/disable MAC changing?

  • a) wizard question, at every boot of netvm [or Whonix-Gateway (netvm)]? [This is what Tails does.] [With wizard I mean something like Tails Greeter or whonix-setup-wizard.]
  • b) wizard question, on first boot of netvm [or Whonix-Gateway (netvm)] only?
  • c) manually only?

I think this may be configured by pre-configuration stack in response on some firstboot option. Then changeable either in Qubes Manager (which will again use pre-configuration stack), or netvm itself (simple configuration dialog, separate shortcut in the menu).

Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing?

adrelanos commented 8 years ago

Agreed.

Can you point the code/implementation details?

It's implemented in Tails. Implementation notes with links to scripts: https://tails.boum.org/contribute/design/MAC_address/#index8h1

Can we reuse some of this?

If going the non-NetworkManager-Plugin route, I guess some things could be reused.

Also interesting: https://wiki.archlinux.org/index.php/MAC_address_spoofing

marmarek commented 8 years ago

If someone help with implementation, it may be included in R3.1. If not, probably in R3.2/R4.0 (whichever comes first).

mfc commented 8 years ago

@adrelanos is this something you could take on? it is very important from a privacy/anonymity perspective.

While we wait for the pre-configuration stack, from Marek's overview it sounds like the simplest initial implementation would be a checkbox in the VM Settings configuration dialog for any netvm, not on by default.

adrelanos commented 8 years ago

@adrelanos is this something you could take on?

No. This is technically very complex and huge task, because you have to do this for every network device before issuing any network traffic and handle [usb] devices being attached during run.

not on by default

As soon as the feature is stable, maybe not in the first release, it should be enabled by default with an option to opt-out.

unman commented 8 years ago

@marmarek I think I see "starting sys-net" as part of systemd startup. When does the sys-net VM actually start? Is it before login? I implement spoofing with systemd using the network-pre target, which runs before Network Manager initiation. Handling USB devices could be done with a udev rule. I'm only using macchanger - is the aim to follow the full tails script?

adrelanos commented 8 years ago

is the aim to follow the full tails script?

  • No. (Concluded from the above discussion.)
  • It's certainly impossible to reuse the Tails implementation as is without modifications.
  • It however makes sense to review their full documentation and implementation because they did all the non-trivial guess work already.
  • A network manager plugin has been considered. Seems also like a more robust solution to me. If this will be the path, then [almost] nothing from Tails code will be used.
adrelanos commented 8 years ago

@adrelanos is this something you could take on?

No. This is technically very complex and huge task, because you have to do this for every network device before issuing any network traffic and handle [usb] devices being attached during run.

The network manager plugin possibility should be discovered first. Probably a much more robust solution than the Tails custom one. However, I can't implement this. Few people are capable of this.

unman commented 8 years ago

@mfc @adrelanos

is the aim to follow the full tails script?

No. (Concluded from the above discussion.) It's certainly impossible to reuse the Tails implementation as is without modifications.

I meant, specifically what features of the Tails script are wanted, as opposed to just using a single call to macchanger. If implemented as systemd service it seems to answer most of the issues raised above, certainly for simplest initial implementation. I dont see conclusion above as to whether users should be able to change setting while netvm is running. Thoughts?

adrelanos commented 8 years ago

unman:

I meant, specifically what features of the Tails script are wanted, as opposed to just using a single call to macchanger.

It needs an analysis first what the features of the Tails implementation actually are.

adrelanos commented 8 years ago

Made a quick analysis by reading all the Tails design and all the linked scripts.

Tails Macchanger Features:

unman commented 8 years ago

I'm familiar with the Tails design.

KISS - changing /lib/systemd/network/99-default.link to use MACAddressPolicy=random Could be done with service early overwriting 99-default.link if enabled.

Individual NIC approach:

[Unit]
Description=macchanger
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

Then calling service for individual NIC. (If don't want ALL)

Either approach has potential for simple immediate implementation, would be configurable using standard Qubes GUI for services and covers many of Tails criteria. Obvious differences-

Either seems preferable to nothing, which is what you have at present.

adrelanos commented 8 years ago

Imho good idea.

Can we do this?

Is this necessary?

Connection failure detection - trivial to implement as per Tails, but probably less helpful than it seems imo.

It would happen for Live USB users who use a shared computer such as in a library. But this might be better implemented by an additional service.

Allows new MAC to equal real MAC: this is based on risk assessment. If I reboot 5 times a day every day, then chance of this happening is once/millennium. I can live with that. The chances of there being major bugs or making trivial user mistake which unmasks seem far higher to me.

With thousands of users the likelyhood increases, that this happens to someone, and no one wants to be the unlucky one. Rather than ExecStart= it could be a path to a script, that does that checking.

Either seems preferable to nothing, which is what you have at present.

But we also don't want snake oil that only mostly works by design.

marmarek commented 8 years ago

On Mon, Oct 26, 2015 at 08:21:44AM -0700, Patrick Schleizer wrote:

Can we do this?

According to this, it's done by patching NetworkMakanger - something we'd like to avoid. But maybe there's another solution? wpa_supplication configuration (if not totally ignored when called from NM)?

Is this necessary?

Since the configuration would be set before actual netvm is started, I don't think so.

Allows new MAC to equal real MAC: this is based on risk assessment. If I reboot 5 times a day every day, then chance of this happening is once/millennium. I can live with that. The chances of there being major bugs or making trivial user mistake which unmasks seem far higher to me.

With thousands of users the likelyhood increases, that this happens to someone, and no one wants to be the unlucky one. Rather than ExecStart= it could be a path to a script, that does that checking.

When script pointed by ExecStart= fails, the service startup fails. If we setup service dependencies correctly it can escalate to netvm startup fail.

Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing?

adrelanos commented 8 years ago

Marek Marczykowski-Górecki:

On Mon, Oct 26, 2015 at 08:21:44AM -0700, Patrick Schleizer wrote:

Can we do this?

According to this, it's done by patching NetworkMakanger - something we'd like to avoid. But maybe there's another solution? wpa_supplication configuration (if not totally ignored when called from NM)?

I think Tails would not patch NetworkManager if there was another option.

Is this necessary?

Since the configuration would be set before actual netvm is started, I don't think so.

I understand leak prevention (w) as this... Without leak prevention, things would happen like this:

1) system boots 2) kernel module loaded 3) MAC leaked 4) macchanger started 5) MAC changed 6) NetworkManager started

So the MAC leaked even before NetworkManager, before the the interface has been uped, before macchanger may have had a chance to change it.

Therefore Tails does as this:

1) system boots with kernel modules blacklisted 2) user makes decision [or in Qubes terms, VM learns decision] 3) kernel module loaded 4) NetworkManger started 5) MAC changed

But if there hypothesis was true... They still have a small window between tails-unblock-network, service network-manager start and macchanger.

Quote 'leak prevention'

It is conceivable that NICs may send packets before the user has made a decision about whether to use MAC spoofing or not. In fact, someone on tails-dev@ alluded to this being possible for wireless NICs although without any references (this may refer to so called "active probing"; see section below). If this is the case it at the very least implies that we must enforce the MAC spoofing setting as early as possible. [...]

That does not sound very certain. But since they're Tails and invested lots of time into this, I take them serious.

Allows new MAC to equal real MAC: this is based on risk assessment. If I reboot 5 times a day every day, then chance of this happening is once/millennium. I can live with that. The chances of there being major bugs or making trivial user mistake which unmasks seem far higher to me.

With thousands of users the likelyhood increases, that this happens to someone, and no one wants to be the unlucky one. Rather than ExecStart= it could be a path to a script, that does that checking.

When script pointed by ExecStart= fails, the service startup fails.

I meant checking if the random MAC equals the real MAC. It could all be written into a long ExecStart= line, but ExecStart=/path/to/script that does this checking and then proper exiting would be better.

If we setup service dependencies correctly it can escalate to netvm startup fail.

Wouldn't that make debugging the issue harder if one cannot start a Konsole?

adrelanos commented 8 years ago

NetworkManager feature request, add support for changing MAC addresses randomly using macchanger https://bugzilla.gnome.org/show_bug.cgi?id=705545

marmarek commented 8 years ago

On Mon, Oct 26, 2015 at 10:01:00AM -0700, Patrick Schleizer wrote:

Marek Marczykowski-Górecki:

On Mon, Oct 26, 2015 at 08:21:44AM -0700, Patrick Schleizer wrote:

Can we do this?

According to this, it's done by patching NetworkMakanger - something we'd like to avoid. But maybe there's another solution? wpa_supplication configuration (if not totally ignored when called from NM)?

I think Tails would not patch NetworkManager if there was another option.

Actually besides that post on the mailing list, I can't find anything about modified NetworkManager in Tails.

Is this necessary?

Since the configuration would be set before actual netvm is started, I don't think so.

I understand leak prevention as this... Without leak prevention, things would happen like this:

1) system boots 2) kernel module loaded 3) MAC leaked 4) macchanger started 5) MAC changed 6) NetworkManager started

So the MAC leaked even before NetworkManager, before the the interface has been uped, before macchanger may have had a chance to change it.

I don't see how that would happen. Interface shouldn't sent anything before being uped and that's done by NetworkManager. For example in case of iwlwifi, the firmware is loaded at the time the interface is uped, so I don't think it is even physically possible to send anything before. Maybe that's about some specific driver case (other that iwlwifi)?

Therefore Tails does as this:

1) system boots with kernel modules blacklisted 2) user makes decision [or in Qubes terms, VM learns decision] 3) kernel module loaded 4) NetworkManger started 5) MAC changed

So this order is wrong - mac should be changed before NetworkManager start.

But if there hypothesis was true... They still have a small window between tails-unblock-network, service network-manager start and macchanger.

Quote 'leak prevention'

It is conceivable that NICs may send packets before the user has made a decision about whether to use MAC spoofing or not. In fact, someone on tails-dev@ alluded to this being possible for wireless NICs although without any references (this may refer to so called "active probing"; see section below). If this is the case it at the very least implies that we must enforce the MAC spoofing setting as early as possible. [...]

That does not sound very certain. But since they're Tails and invested lots of time into this, I take them serious.

I think that all is because in Tails, the user can make the decision pretty late in system startup. In our case, it can be set before starting any service.

Allows new MAC to equal real MAC: this is based on risk assessment. If I reboot 5 times a day every day, then chance of this happening is once/millennium. I can live with that. The chances of there being major bugs or making trivial user mistake which unmasks seem far higher to me.

With thousands of users the likelyhood increases, that this happens to someone, and no one wants to be the unlucky one. Rather than ExecStart= it could be a path to a script, that does that checking.

When script pointed by ExecStart= fails, the service startup fails.

I meant checking if the random MAC equals the real MAC. It could all be written into a long ExecStart= line, but ExecStart=/path/to/script that does this checking and then proper exiting would be better.

If you randomly hit your own MAC address, I think this isn't a problem at all. Actually changing that behaviour may introduce some bias in that randomness. But if you're talking about some error which results in not changing the MAC (even if randomly chosen one was different than original), that's the problem.

If we setup service dependencies correctly it can escalate to netvm startup fail.

Wouldn't that make debugging the issue harder if one cannot start a Konsole?

One can always open virsh console. And there would wait shell prompt. But probably this can be also arranged to only prevent NetworkManager startup. I think the right type of dependency is Requires=. If set (together with After=) on NetworkManager.service, NetworkManager should not start, if the mac changing service fails to start.

Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing?

unman commented 8 years ago

With thousands of users the likelyhood increases, that this happens to someone, and no one wants to be the unlucky one.

I don't think risk analysis works like this. I don't increase my chances of winning the lottery by encouraging others to take part.

Either seems preferable to nothing, which is what you have at present.

But we also don't want snake oil that only mostly works by design.

"Snake oil" is pretty emotive, particularly as it isn't clear yet what "works" means in this context. I agree with @marmarek : getting the dependencies right is essential. As @mfc said, this is an important feature. Putting something in place is better than nothing, even if not ideal: it doesn't have to be the the final solution. The systemd route seems to cover most requirements, particularly given the existing Qubes infrastructure. Note that Tails "don't use [systemd integration] yet", which suggests they are moving that way.

HulaHoopWhonix commented 8 years ago

While it makes sense for TAILS to automatically change the MAC every boot (because they are a LiveOS) this is problematic for people who connect from behind captive portals that allow access based on a static MAC address. Most business locations and hotels allow access in an unopen way so having automatic MAC changing by default doesn't make sense.

Another solution is to "pin" a MAC address to a saved connection profile. But this brings all kinds of problems similar to LAN profiling hurdles TAILS documented for choosing persistent guards according to hotspot SSID.

This leaves the only sane solution: manually setting the MAC depending on the users judgement. To add value to such a management tool you will need some way of simultaneously changing guard nodes too for compete tracking protection.

It's a huge undertaking and I think we should see if TAILS can add more options to their tool and just use that.

adrelanos commented 8 years ago

unman:

With thousands of users the likelyhood increases, that this happens to someone, and no one wants to be the unlucky one.

I don't think risk analysis works like this. I don't increase my chances of winning the lottery by encouraging others to take part.

You don't. Right. But the distribution, Qubes doing it that way would increase chances to have this happen to unlucky one.

Either seems preferable to nothing, which is what you have at present.

But we also don't want snake oil that only mostly works by design.

"Snake oil" is pretty emotive, particularly as it isn't clear yet what "works" means in this context. I agree with @marmarek : getting the dependencies right is essential. As @mfc said, this is an important feature. Putting something in place is better than nothing, even if not ideal: it doesn't have to be the the final solution. The systemd route seems to cover most requirements, particularly given the existing Qubes infrastructure. Note that Tails "don't use [systemd integration] yet", which suggests they are moving that way.

Ok. Go for the simple implementation. Would be trivial to put this as enhancement on top.

adrelanos commented 8 years ago

HulaHoopWhonix:

While it makes sense for TAILS to automatically change the MAC every boot (because they are a LiveOS) this is problematic for people who connect from behind captive portals that allow access based on a static MAC address. Most business locations and hotels allow access in an unopen way so having automatic MAC changing by default doesn't make sense.

Another solution is to "pin" a MAC address to a saved connection profile. But this brings all kinds of problems similar to LAN profiling hurdles TAILS documented for choosing persistent guards according to hotspot SSID.

This leaves the only sane solution: manually setting the MAC depending on the users judgment. To add value to such a management tool

'manually setting the MAC depending on the users judgment' is impossible to communicate and implement UX wise. That's prone to fail. Something only advanced users understanding and getting right. Also somewhat sounds like a bigger feature "connection profiles".

you will need some way of simultaneously changing guard nodes too for compete tracking protection.

TLDR:

Much too complicated for the first iteration. (And unclear if a sound concept.)

Long:

Conceptual:

Since guards were (by TPO) reduced to 1 by default, they should be much less fingerprintable?

With very few Tor users in an open hotspot, a random MAC + same guard, may yield "it's probably the same one".

Related:

But what to do? Every time the user is one the same hotspot, use a different MAC + entry guard? What if the user goes there every day or so? That would result in a lot entry guards that would get used. And therefore, the likelihood to pick a hostile entry guard would increase. Eventually that would defeat the very purpose behind entry guards.

What about home internet connections? People keep using the same entry guard there also.

And what does the adversary learn? "it's probably the same one" - Still no destinations or traffic content.

From home internet connections it's also "it's probably the same one".

If Tor and "it's probably the same one" should be hidden, the only option is (obfuscated) bridges, hiding Tor from ISPs. Related: https://www.whonix.org/wiki/Hide_Tor_and_Whonix_from_your_ISP

Technical aspect:

Very difficult to implement. More so, in Qubes, where the MAC changing is done in NetVM and Tor entry guards are picked by Tor in other VMs (Whonix-Gateway, ...).

It's a huge undertaking and I think we should see if TAILS can add more options to their tool and just use that.

Please open feature requests against Tails as appropriate. They have a bigger team, including UX designers.

quu9ohch commented 8 years ago

Randomizing all hardware mac addresses in Qubes OS only requires a simple change to the configuration files of systemd in the default netVM and we recommend that this be the default configuration packaged by the official Qubes developers. Here's how to change it in Qubes 3.0 - Step 1. Open a terminal on the fedora-21 template VM in which to type the following commands. Step 2. Create a configuration file to preserve the static mac addresses of qubes provided virtual nics with the following command: sudo sh -c 'printf "[Match]\nMACAddress=fe:ff:ff:ff:ff:ff\n[Link]\nNamePolicy=kernel database onboard slot path\nMACAddressPolicy=persistent\n" > /usr/lib/systemd/network/98-xen-provided.link' Step 3. Modify the default link configuration file to create random mac addresses for all other nics: sudo sed -i s/MACAddressPolicy=persistent/MACAddressPolicy=random/ /usr/lib/systemd/network/99-default.link

These instructions were modeled on method 2.1 for mac address spoofing given at https://wiki.archlinux.org/index.php/MAC_Address_Spoofing

quu9ohch commented 8 years ago

Also, with systemd configuration given above, it is easy to pin a static mac address to any connection profile. In addition to using the Network Manager text configuration files, you can do this with the graphical interface by simply right clicking on the network manger icon, then click Edit Connections->Edit(or Add)->Wi-Fi(or Ethernet) and enter your static mac address into the "Cloned MAC address field". This is the ideal configuration because even those users who want a static address should not be using the factory assigned address (only excuse is collision prevention with other macs, but this is a bogus argument because using a factory address on your computer does not prevent collisions with other computers who may be spoofing any better than a random address - in fact it is worse). Users of static addresses should be, ideally, assigned those addresses by their network admin, not their nic manufacturer.

Finally, all these arguments about randomly choosing from only a subset of all possible mac addresses are totally bogus. It is not possible to "blend into the crowd" with a "typical-looking" mac address when so many users allow themselves to be uniquely fingerprinted and tracked. The tradeoff of using a weird (or never manufactured) mac address is like the tradeoff of using tor. It follows from the pigeon hole principle that one cannot hide the fact that they are trying to hide (it is up to other users to hide you), but the best one can do is become statistically exchangeable with the largest possible set of anonymity participants via randomness.

It says at https://tails.boum.org/contribute/design/MAC_address/ that "systemd integration: We don't use this yet." - well Qubes already does use it, someone just needs to put the right configuration files in the official repositories.

quu9ohch commented 8 years ago

P.S. Avoiding the "real" mac address is a bogus approach as well. If all users were to avoid their real mac addresses all the time then, with enough data, a local passive adversary could identify each user by estimating which mac address they never pick.

P.P.S. The fingerprint of all connection profiles leaking is a subtler issue. If the user uses Network Manager to set static addresses, then the leak only comes from an unaffiliated random (disposable) mac address (and only to eavesdroppers within wifi range logging at that level of detail -- unlikely for the untargeted users addressed by tor's threat model), but if the user always uses randomized addresses then I think the leak would be associated with the same mac randomized address of the current session. The only way to fix this is to disable the protocol speedup for discovering preferred ssids (perhaps, also through Network Manger configuration files), otherwise replace it with a redesigned protocol.

adrelanos commented 8 years ago

@quu9ohch, please consider suggesting this to the Tails developers also. (Arguments about "blend into the crowd", "typical-looking" mac address, hide real mac.) It would be valuable to have this discussions and them perhaps come up with the same solution as Qubes.

P.P.S. The fingerprint of all connection profiles leaking is a subtler issue. If the user uses Network Manager to set static addresses, then the leak only comes from an unaffiliated random (disposable) mac address (and only to eavesdroppers within wifi range logging at that level of detail -- unlikely for the untargeted users addressed by tor's threat model), but if the user always uses randomized addresses then I think the leak would be associated with the same mac randomized address of the current session. The only way to fix this is to disable the protocol speedup for discovering preferred ssids (perhaps, also through Network Manger configuration files), otherwise replace it with a redesigned protocol.

Is this what Tails describes as Active probe fingerprinting?

mfc commented 8 years ago

Ok. Go for the simple implementation.

anyone aiming to work on the simple implementation of this?

re: the more complicated issues raised, it'd probably be good to start a thread on the Secure Desktops mailing list to get the Tails and Subgraph devs' thoughts.

adrelanos commented 8 years ago

re: the more complicated issues raised, it'd probably be good to start a thread on the Secure Desktops mailing list to get the Tails and Subgraph devs' thoughts.

Various threads have been posted.

mfc commented 8 years ago

great, thanks for creating those threads Patrick. with more clarification about how Tails does it it should make it easier for use to create a simple implementation, since these research threads will probably continue for some time before coming to fruition

mfc commented 8 years ago

so any concrete take-aways from those mailing list discussions, or from 32c3?

this is a significant feature that Qubes stands out as lacking compared to Tails or Subgraph. would be nice to have something that we can iterate/improve upon, as the other projects are doing.

isislovecruft commented 8 years ago

There's a comment from @unman from October 2015 above which is the answer to this problem. Separately, before finding this ticket, I came up with the similar solution of using a systemd service as follows in the TemplateVM for sys-net:

user@fedora-23 $ cat /etc/systemd/system/macspoof\@.service
[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 -r %I
Type=oneshot

[Install]
WantedBy=multi-user.target

Then I don't remember the exact commands, but it was something like:

user@fedora-23 $ sudo dnf install macchanger
user@fedora-23 $ touch /var/run/qubes-service/macspoof-wlp0s1
user@fedora-23 $ touch /var/run/qubes-service/macspoof-enp0s0
user@sys-net $ sudo systemctl enable macspoof@wlp0s1
user@sys-net $ sudo systemctl enable macspoof@enp0s0

Then, IIRC, I needed to check the little corresponding checkboxes in the "Services" tab for sys-net in the Qubes Manager.

I've been using this for months and not had any problem.

bnvk commented 8 years ago

Thanks @isislovecruft I fiddled a bit with this and figured out the order and specifics. I created a page of documentation about this that others can test. Will send a pull-request once someone confirms as such!

mfc commented 8 years ago

tremendous job @bnvk, @isislovecruft, and @unman! I have followed, cleaned up, and verified your instructions @bnvk.

please note I changed the default suggestion from @isislovecruft's macchanger -r to @unman's macchanger -e and explained why in the documentation. Basically, it would be helpful towards anonymity if the MAC spoofing was not obvious to a network adversary, see Tails' notes on the subject. But ultimately the choice is with the user, so I have highlight both options to the user at the proper step of the documentation.

next up is to think about this as a potential checkbox in firstboot under selecting sys-whonix by default.

tasket commented 8 years ago

This appears to leave the original mac exposed when waking from sleep, requiring the user to shutdown all their net-dependant vms so that sys-net can be restarted (and the mac has already been broadcast anyway... to avoid leaking the mac addr. a sleeping system must be forced to power off before it has a chance to wake).

Proper implementation is made possible by a new feature in wpa_supplicant 2.4 -- which f23 already has. :) You also need the new networkmanager 1.2, which allows random mac spoofing both while scanning and while connected.

https://blogs.gnome.org/lkundrak/2016/04/20/networkmanager-1-2-is-here/

I do not see a backport of networkmanager 1.2 for f23, but it will be in f24. Since an alpha of f24 is available (full release in June), perhaps the best way forward is to start work on an f24 template.

mfc commented 8 years ago

This appears to leave the original mac exposed when waking from sleep, requiring the user to shutdown all their net-dependant vms so that sys-net can be restarted (and the mac has already been broadcast anyway... to avoid leaking the mac addr. a sleeping system must be forced to power off before it has a chance to wake).

I am unable to confirm this, mine still broadcasts spoofed mac address when waking from sleep.

networkmanager 1.2 sounds pretty great, while we wait this seems like a decent DIY solution.

tasket commented 8 years ago

@mfc Unfortunately, my own tests with automating macchanger last year showed my NICs would revert to their original addresses on wake -- Always. So maybe it is "always on certain NICs but not others".

At this point I feel a vertically-integrated approach is needed to implement this feature properly. That means NM and WPAS versions written with these specific, privacy use cases in mind.

unman commented 8 years ago

@ttasket My testing with variety NICs never showed leakage on waking, so it may well be the NIC - please identify yours so that caveat can be added to documentation.

I wasn't happy with waking sys-net, so I now change netvm from sys-net and shutdown sys-net on sleep. That seems cleaner. Also, I switched to simple udev rule which has the benefit of randomising new devices as inserted.

tasket commented 8 years ago

I just performed a simple test:

  1. Disable wifi in NM
  2. sudo 'macchanger -e wlan0'
  3. Enable wifi and connect with new address
  4. Verify with ifconfig that wlan0 is using new address
  5. Sleep system
  6. Wake 5min later
  7. Check ifconfig again

The last step showed the address had returned to the original. The adapter is an Intel Centrino Ultimate-N 6300.

As plausible as an attempt at a scripted solution may seem, I think it is even more likely that such an attempt would cover up a reality where some/all users are having their original mac addresses exposed anyway: For instance, if firmware resets the address on waking and then macchanger is run to re-set a random address, then there is a good chance the necessary address changes won't occur before the NIC starts scanning using the original address.

Another example to consider is the debian 8 macchanger package: You can specify at install time that mac addresses are randomized "each time an interface is brought up or down". I am fairly sure their solution will leave wlan0 with a random address after I wake the system check it with ifconfig... but I don't trust it to do a thorough job.

The authors of wpa_supplicant and Network Manager are going out of their way to accommodate this feature -- that is a strong signal of the uncertainties when using systemd and scripts.

andrewdavidwong commented 8 years ago

Is anyone currently working on this? I'm asking for tracking purposes.

tasket commented 8 years ago

Conversation with NM devs here: https://mail.gnome.org/archives/networkmanager-list/2016-April/msg00084.html

TL;dr is that full randomization (i.e. while connected to an AP) from NM and wpasupplicant probably won't be available soon because they now have a requirement that the feature have a dbus interface. But wpas didn't add full randomization to the dbus interface until v2.5 (fedora 23 uses 2.4 and debian 8 uses 2.3). Also, there was a bug preventing this in NM and the patch might not get backported to NM 1.2 or earlier.

There is also the point about supporting the use case where a user permanently assigns random MAC addresses to each connection object they have in NM. In order to be really un-trackable, both NM and wpas would have to coordinate sufficiently to prevent the hardware address from popping up when shifting between scanning and connecting (both programs exert control over the MAC address depending on the mode).

The upshot is that wpas 2.4 in fedora should do scanning/pre-connection randomization on its own. But I'd want to test this before making any assertion.

andrewdavidwong commented 8 years ago

@ttasket: Thanks for the update! Do you plan to continue testing/working on this? (May I assign this to you for tracking purposes?)

tasket commented 8 years ago

@andrewdavidwong Sure, assign it to me and I'll keep nudging the NM/wpas pathway and try out the patched versions.

andrewdavidwong commented 8 years ago

@ttasket: Great! Thank you!

adrelanos commented 8 years ago

@unman posted a PR: https://github.com/QubesOS/qubes-doc/pull/166

andrewdavidwong commented 8 years ago

@marmarek: It looks like this issue has changed from the original "support a patch for iwlwifi" to "document methods for mac randomization." Is that correct?

In other words, do we need code contributions to close this, or will documentation contributions suffice?