Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.
Sign upMAC Randomization for iwlwifi #938
Comments
marmarek
added
enhancement
C: other
P: major
labels
Mar 8, 2015
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
mfc
Oct 3, 2015
Member
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
|
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 |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
adrelanos
Oct 4, 2015
Member
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.
- always randomize MAC is wrong, can draw extra unwanted attention -> depends on threat model and network the user is using
- some times MAC randomization breaks the network connection
- therefore requires a GUI and asking the user questions
Points to more information:
- https://tails.boum.org/doc/first_steps/startup_options/mac_spoofing/
- https://tails.boum.org/contribute/design/MAC_address/
- https://www.whonix.org/wiki/Pre_Install_Advice#MAC_Address
- https://www.whonix.org/wiki/Dev/MAC
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.
|
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:
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. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
mfc
Oct 4, 2015
Member
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.
|
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. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Oct 4, 2015
Member
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?
|
On Sun, Oct 04, 2015 at 02:42:29PM -0700, Michael Carbone wrote:
Whonix-gateway (and more importantly whonix-workstation) does not have But still sometimes useful option. IMHO it would be the best if possible Best Regards, |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
mfc
Oct 4, 2015
Member
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.
ah apologies thanks for clarifying this would need to be implemented in netvm. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
adrelanos
Oct 5, 2015
Member
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,
-
- 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.
-
- 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.)
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
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?
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?
|
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Oct 5, 2015
Member
On Mon, Oct 05, 2015 at 12:25:47AM -0700, Patrick Schleizer wrote:
- 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.
- 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?
|
On Mon, Oct 05, 2015 at 12:25:47AM -0700, Patrick Schleizer wrote:
I think it should be possible to use this feature even without Whonix,
Can you point the code/implementation details? Can we reuse some of
I think this may be configured by pre-configuration stack in response on Best Regards, |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
adrelanos
Oct 5, 2015
Member
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
|
Agreed.
It's implemented in Tails. Implementation notes with links to scripts:
If going the non-NetworkManager-Plugin route, I guess some things could be reused. Also interesting: |
marmarek
added
the
help wanted
label
Oct 9, 2015
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Oct 9, 2015
Member
If someone help with implementation, it may be included in R3.1. If not, probably in R3.2/R4.0 (whichever comes first).
|
If someone help with implementation, it may be included in R3.1. If not, probably in R3.2/R4.0 (whichever comes first). |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
mfc
Oct 23, 2015
Member
@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 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. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
adrelanos
Oct 23, 2015
Member
@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.
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.
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. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
unman
Oct 24, 2015
Member
@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?
|
@marmarek |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
adrelanos
Oct 25, 2015
Member
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.
|
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
adrelanos
Oct 25, 2015
Member
@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.
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. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
unman
Oct 25, 2015
Member
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?
I meant, specifically what features of the Tails script are wanted, as opposed to just using a single call to macchanger. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
adrelanos
Oct 26, 2015
Member
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.
|
unman:
It needs an analysis first what the features of the Tails implementation |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
adrelanos
Oct 26, 2015
Member
Made a quick analysis by reading all the Tails design and all the linked scripts.
Tails Macchanger Features:
- graphical user interface to toggle the setting: yes (in Tails Greeter)
- enabled by default: yes
- can be opted out on boot when choosing advanced: yes
- setting can be changed during run: ?
- Active probe fingerprinting defense: says no / says yes
- only spoof the NIC part: yes
- OUI part unchanged: yes
- leak prevention (w), Network blocking, blacklist kernel modules from being load before the user made a decision: yes
- prevent devices attached during run from leaking the MAC: yes
- failing closed, keep network disabled if MAC could not be changed: yes
- down interface if mac changing failed when blacklisting was insufficient: yes
- graphical notification in case of failure: yes
- verify, that randomly chosen MAC does not equal the real MAC by chance: yes
- connection failure detection, graphical notification: yes
|
Made a quick analysis by reading all the Tails design and all the linked scripts. Tails Macchanger Features:
|
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
unman
Oct 26, 2015
Member
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-
- Connection failure detection - trivial to implement as per Tails, but probably less helpful than it seems imo.
- 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.
Either seems preferable to nothing, which is what you have at present.
|
I'm familiar with the Tails design. KISS - Individual NIC approach: 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.
Either seems preferable to nothing, which is what you have at present. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
adrelanos
Oct 26, 2015
Member
Imho good idea.
- Active probe fingerprinting defense: says no / says yes
Can we do this?
- leak prevention, Network blocking, blacklist kernel modules from being load before the user made a decision: yes
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.
|
Imho good idea.
Can we do this?
Is this necessary?
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.
With thousands of users the likelyhood increases, that this happens to someone, and no one wants to be the unlucky one. Rather than
But we also don't want snake oil that only mostly works by design. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Oct 26, 2015
Member
On Mon, Oct 26, 2015 at 08:21:44AM -0700, Patrick Schleizer wrote:
- Active probe fingerprinting defense: says no / says yes
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)?
- leak prevention, Network blocking, blacklist kernel modules from being load before the user made a decision: yes
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?
|
On Mon, Oct 26, 2015 at 08:21:44AM -0700, Patrick Schleizer wrote:
According to
Since the configuration would be set before actual netvm is started, I
When script pointed by Best Regards, |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
adrelanos
Oct 26, 2015
Member
Marek Marczykowski-Górecki:
On Mon, Oct 26, 2015 at 08:21:44AM -0700, Patrick Schleizer wrote:
- Active probe fingerprinting defense: says no / says yes
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_supplicationconfiguration (if
not totally ignored when called from NM)?
I think Tails would not patch NetworkManager if there was another option.
- leak prevention, Network blocking, blacklist kernel modules from being load before the user made a decision: yes
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:
- system boots
- kernel module loaded
- MAC leaked
- macchanger started
- MAC changed
- 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:
- system boots with kernel modules blacklisted
- user makes decision [or in Qubes terms, VM learns decision]
- kernel module loaded
- NetworkManger started
- 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?
|
Marek Marczykowski-Górecki:
I think Tails would not patch NetworkManager if there was another option.
I understand leak prevention (w) as this... Without leak prevention, things would happen like this:
So the MAC leaked even before NetworkManager, before the the interface has been Therefore Tails does as this:
But if there hypothesis was true... They still have a small window between tails-unblock-network, Quote 'leak prevention'
That does not sound very certain. But since they're Tails and invested lots of time into this, I take them serious.
I meant checking if the random MAC equals the real MAC. It could all be written into a long
Wouldn't that make debugging the issue harder if one cannot start a Konsole? |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
adrelanos
Oct 26, 2015
Member
NetworkManager feature request,
add support for changing MAC addresses randomly using macchanger
https://bugzilla.gnome.org/show_bug.cgi?id=705545
|
NetworkManager feature request, |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Oct 26, 2015
Member
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:
- Active probe fingerprinting defense: says no / says yes
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_supplicationconfiguration (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.
- leak prevention, Network blocking, blacklist kernel modules from being load before the user made a decision: yes
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:
- system boots
- kernel module loaded
- MAC leaked
- macchanger started
- MAC changed
- 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:
- system boots with kernel modules blacklisted
- user makes decision [or in Qubes terms, VM learns decision]
- kernel module loaded
- NetworkManger started
- 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 startand 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, butExecStart=/path/to/scriptthat 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?
|
On Mon, Oct 26, 2015 at 10:01:00AM -0700, Patrick Schleizer wrote:
Actually besides that post on the mailing list, I can't find anything
I don't see how that would happen. Interface shouldn't sent anything
So this order is wrong - mac should be changed before NetworkManager
I think that all is because in Tails, the user can make the decision
If you randomly hit your own MAC address, I think this isn't a problem
One can always open virsh console. And there would wait shell prompt. Best Regards, |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
unman
Oct 26, 2015
Member
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.
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.
"Snake oil" is pretty emotive, particularly as it isn't clear yet what "works" means in this context. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
HulaHoopWhonix
Oct 27, 2015
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.
HulaHoopWhonix
commented
Oct 27, 2015
|
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. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
adrelanos
Nov 2, 2015
Member
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.
|
unman:
You don't. Right. But the distribution, Qubes doing it that way would
Ok. Go for the simple implementation. Would be trivial to put this as |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
adrelanos
Nov 2, 2015
Member
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:
- https://lists.torproject.org/pipermail/tor-talk/2012-October/025975.html
- https://trac.torproject.org/projects/tor/ticket/2653
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.
|
HulaHoopWhonix:
'manually setting the MAC depending on the users judgment' is impossible
TLDR: Much too complicated for the first iteration. Long: Conceptual: Since guards were (by TPO) reduced to 1 by default, they With very few Tor users in an open hotspot, a random MAC + same guard, Related:
But what to do? Every time the user is one the same hotspot, use a What about home internet connections? People keep using the same entry And what does the adversary learn? "it's probably the same one" - Still 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 Technical aspect: Very difficult to implement. More so, in Qubes, where the MAC changing
Please open feature requests against Tails as appropriate. They have a |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
quu9ohch
Nov 11, 2015
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
Nov 11, 2015
|
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 - These instructions were modeled on method 2.1 for mac address spoofing given at https://wiki.archlinux.org/index.php/MAC_Address_Spoofing |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
quu9ohch
Nov 11, 2015
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
Nov 11, 2015
|
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. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
quu9ohch
Nov 11, 2015
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.
quu9ohch
commented
Nov 11, 2015
|
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. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
adrelanos
Nov 11, 2015
Member
@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?
|
@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.
Is this what Tails describes as |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
mfc
Nov 23, 2015
Member
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.
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. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
adrelanos
Nov 26, 2015
Member
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.
- Tails: Protect against fingerprinting via active Wi-Fi networks probing implemented?
- Tails' MAC 'leak prevention' question
- Some thoughts on MAC spoofing (on the reliability of changing MAC addresses by using macchanger, interplay with hardware)
- MAC changer "blend into the crowd" by only using common manufacturer MAC (OUI part) addresses broken by design?
- Avoiding real MAC address in Tails macchanger being harmful?
Various threads have been posted.
|
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
mfc
Nov 27, 2015
Member
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
|
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 |
marmarek
added this to the Far in the future milestone
Jan 7, 2016
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
mfc
Jan 24, 2016
Member
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.
|
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. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
andrewdavidwong
Jun 18, 2016
Member
@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?
andrewdavidwong
commented
Jun 18, 2016
•
edited
Edited 1 time
-
andrewdavidwong
edited Jun 18, 2016 (most recent)
edited
-
Jun 18, 2016 (most recent)
|
@marmarek: It looks like this issue has changed from the original "support a patch for In other words, do we need code contributions to close this, or will documentation contributions suffice? |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
tasket
Jun 18, 2016
We still have a NM/wpas solution pending, but will take many months before it reaches the normal template repositories. So we may want to track the effort to test and document it for Qubes.
tasket
commented
Jun 18, 2016
|
We still have a NM/wpas solution pending, but will take many months before it reaches the normal template repositories. So we may want to track the effort to test and document it for Qubes. |
added a commit
that referenced
this issue
Jun 20, 2016
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
adrelanos
Jun 23, 2016
Member
A patch has been attached to the NetworkManager upstream feature request add support for changing MAC addresses randomly using macchanger:
https://bugzilla.gnome.org/show_bug.cgi?id=705545
|
A patch has been attached to the NetworkManager upstream feature request |
added a commit
that referenced
this issue
Jun 23, 2016
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
adrelanos
Jul 7, 2016
Member
Why MAC Address Randomization is not Enough:
An Analysis of Wi-Fi Network Discovery Mechanisms
|
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
adrelanos
Jul 7, 2016
Member
[Secure Desktops] Why MAC Address Randomization is not Enough: An Analysis of Wi-Fi Network Discovery Mechanisms:
https://secure-os.org/pipermail/desktops/2016-July/000129.html
|
|
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
tasket
Jul 7, 2016
Thanks Patrick. Very interesting. It looks like we have got on a ladder of incremental progress.
tasket
commented
Jul 7, 2016
|
Thanks Patrick. Very interesting. It looks like we have got on a ladder of incremental progress. |
added a commit
that referenced
this issue
Jul 9, 2016
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
tasket
Aug 30, 2016
Status update:
The NM team says that WPAS will not have the required API for any randomization until at least v2.6, so even having NM 1.2 in a typical distro like Debian 9 with WPAS 2.4--which I am already testing on Qubes--will not help bring this feature to users.
However, NM 1.4 has re-factored the random features in such a way that bypasses WPAS:
https://blogs.gnome.org/thaller/2016/08/26/mac-address-spoofing-in-networkmanager-1-4-0/
The good news is that NM 1.4 has already landed in Debian unstable and Fedora 25. Maybe we'll see official backport(s) available for Debian 9 and/or Fedora 23.
tasket
commented
Aug 30, 2016
|
Status update: However, NM 1.4 has re-factored the random features in such a way that bypasses WPAS: The good news is that NM 1.4 has already landed in Debian unstable and Fedora 25. Maybe we'll see official backport(s) available for Debian 9 and/or Fedora 23. |
added a commit
that referenced
this issue
Aug 31, 2016
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
andrewdavidwong
Sep 15, 2016
Member
Subject: macspoof broken in 3.2rc3
On 2016-09-08 06:29, throw_away@sigaint.org wrote:
*** Expected behavior: macspoof script automatically scrambles network
interface MACs at sys-net startup using instructions from [1], just like
in R3.1.[1] https://www.qubes-os.org/doc/anonymizing-your-mac-address/
*** Actual behavior:
[user@sys-net ~]$ sudo systemctl status macspoof@wlp0s1
● macspoof@wlp0s1.service - macchanger on wlp0s1
Loaded: error (Reason: Invalid argument)
Active: inactive (dead)Same on wired interface. ifconfig confirms MAC addresses are not changed.
*** Workaround:
Set configured wireless networks to not automatically connect; and start
the computer with no connected Ethernet cables. Then:[In sys-net:]
sudo ifconfig wlp0s1 down
sudo macchanger -r wlp0s1
sudo ifconfig wlp0s1 up
[Repeat as necessary for each interface for which randomized MAC is desired.][Manually connect to wireless network using Network Manager applet, plug
in cable, etc.]*** Additional notes:
Could it be something flaky with my hardware's interaction with new
drivers? IIUC, sys-net was/is the same fedora-23 in both R3.1 and R3.2rc3.
So, same drivers. Or could a qubes-specific startup script ordering be now
wrong?Thanks!
|
Subject: macspoof broken in 3.2rc3 On 2016-09-08 06:29, throw_away@sigaint.org wrote:
|
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
tasket
Oct 3, 2016
Update!
https://groups.google.com/d/msgid/qubes-users/0300e698-0120-e9bb-65d4-b4bd0a3d54f1%40openmailbox.org
Although Network Manager 1.4.0 had problems connecting, the new 1.4.2 version has been testing very well for me the last few days. It randomizes MAC addresses properly, adds some nice options and works in my Debian 9 template. See above thread for more.
So I think closing this issue is now on the horizon. I'd also recommend opening a new issue for the problem raised by the Mathy Vanhoef paper that Patrick linked to.
tasket
commented
Oct 3, 2016
|
Update! https://groups.google.com/d/msgid/qubes-users/0300e698-0120-e9bb-65d4-b4bd0a3d54f1%40openmailbox.org Although Network Manager 1.4.0 had problems connecting, the new 1.4.2 version has been testing very well for me the last few days. It randomizes MAC addresses properly, adds some nice options and works in my Debian 9 template. See above thread for more. So I think closing this issue is now on the horizon. I'd also recommend opening a new issue for the problem raised by the Mathy Vanhoef paper that Patrick linked to. |
added a commit
that referenced
this issue
Oct 4, 2016
andrewdavidwong
referenced this issue
Oct 4, 2016
Open
Explore local network privacy solutions beyond MAC address randomization #2361
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
andrewdavidwong
Oct 4, 2016
Member
@tasket: Thanks for the update! Tracker updated and new issue created.
|
@tasket: Thanks for the update! Tracker updated and new issue created. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
tasket
Oct 11, 2016
NM 1.4.2 just migrated from debian unstable to testing/9. This makes describing installation much simpler, so I'll submit changes to the MAC randomization doc to show this as an option.
tasket
commented
Oct 11, 2016
•
edited
Edited 1 time
-
tasket
edited Oct 11, 2016 (most recent)
edited
-
Oct 11, 2016 (most recent)
|
NM 1.4.2 just migrated from debian unstable to testing/9. This makes describing installation much simpler, so I'll submit changes to the MAC randomization doc to show this as an option. |
tasket
referenced this issue
in QubesOS/qubes-doc
Oct 13, 2016
Merged
Add section for Network Manager on Debian 9 #200
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
tasket
commented
Oct 13, 2016
|
PR here QubesOS/qubes-doc#200 |
added a commit
that referenced
this issue
Nov 6, 2016
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
andrewdavidwong
Nov 15, 2016
Member
Confirming that this macchanger bug is still present in R3.2 stable.
|
Confirming that this macchanger bug is still present in R3.2 stable. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
andrewdavidwong
Dec 16, 2016
Member
Additional user reports of MAC randomization not working (possibly extended beyond previously mentioned macchanger bug): https://groups.google.com/d/topic/qubes-users/3Sy-Wa1Os-k/discussion
|
Additional user reports of MAC randomization not working (possibly extended beyond previously mentioned macchanger bug): https://groups.google.com/d/topic/qubes-users/3Sy-Wa1Os-k/discussion |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
tasket
Dec 16, 2016
@andrewdavidwong It should work fine. Doc was changed to use incorrect keyword. See https://groups.google.com/d/msgid/qubes-users/d48883d4-6ebb-56ba-c70b-a2d1d16286fa%40openmailbox.org
tasket
commented
Dec 16, 2016
|
@andrewdavidwong It should work fine. Doc was changed to use incorrect keyword. See https://groups.google.com/d/msgid/qubes-users/d48883d4-6ebb-56ba-c70b-a2d1d16286fa%40openmailbox.org |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
tasket
commented
Dec 16, 2016
|
PR here: QubesOS/qubes-doc#244 |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
andrewdavidwong
Dec 16, 2016
Member
@tasket: This applies only to the NetworkManager method, not the Macchanger method, right? So the Macchanger bug persists.
|
@tasket: This applies only to the NetworkManager method, not the Macchanger method, right? So the Macchanger bug persists. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
tasket
commented
Dec 16, 2016
|
@andrewdavidwong : Correct, its for NetworkManager instructions. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
tasket
Dec 16, 2016
FWIW, I think making macchanger work correctly appears unlikely. Over the span of 12 years gnu.org updated it only once (or so it appears on their site) and may have dropped it. Distros like Debian packaged scripts and triggers with macchanger that didn't work either. It never got beyond being experimental.
Robust randomization was added to NIC management stacks in iOS, Windows, Android and now Linux in Network Manager. This was necessary because they are designed to manage NICs at all phases of operation and thus are the best fit for the non-trivial task of keeping a NICs native address suppressed.
You might consider closing the issue and eventually retiring the macchanger instructions once NM >= 1.4.2 becomes standard-issue in the templates.
tasket
commented
Dec 16, 2016
|
FWIW, I think making macchanger work correctly appears unlikely. Over the span of 12 years gnu.org updated it only once (or so it appears on their site) and may have dropped it. Distros like Debian packaged scripts and triggers with macchanger that didn't work either. It never got beyond being experimental. Robust randomization was added to NIC management stacks in iOS, Windows, Android and now Linux in Network Manager. This was necessary because they are designed to manage NICs at all phases of operation and thus are the best fit for the non-trivial task of keeping a NICs native address suppressed. You might consider closing the issue and eventually retiring the macchanger instructions once NM >= 1.4.2 becomes standard-issue in the templates. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
|
That sounds reasonable, once 1.4.2 lands in stable. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
andrewdavidwong
Apr 10, 2017
Member
On 2017-04-09 15:25, Joonas Lehtonen wrote:
Hi,
if you setup MAC randomization via network manager in a debian 9
template as described here:
https://www.qubes-os.org/doc/anonymizing-your-mac-address/
you still leak your hostname.Once your MAC address is randomized you might also want to prevent the
disclosure of your netvm's hostname to the network, since "sys-net"
might be a unique hostname (that links all your random MAC addresses and
the fact that you likely use qubes).To prevent the hostname leak via DHCP option (12):
- start the debian 9 template
- open the file /etc/dhcpd/dhclient.conf
- in line number 15 you should see "send host-name = gethostname();"
- comment (add "#" at the beginning) or remove that line and store the file
- reboot your netvm
I tested the change via inspecting dhcp requests and can confirm that
the hostname is no longer included in dhcp requests.
|
On 2017-04-09 15:25, Joonas Lehtonen wrote:
|
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
|
FYI there is a typo, should be: |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
tasket
Apr 10, 2017
For reference, a new paper on tracking mobile devices:
https://arxiv.org/pdf/1703.02874v1.pdf
I don't think Linux laptops would fare much better than the Android devices cited.
tasket
commented
Apr 10, 2017
|
For reference, a new paper on tracking mobile devices: https://arxiv.org/pdf/1703.02874v1.pdf I don't think Linux laptops would fare much better than the Android devices cited. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
tasket
Apr 26, 2017
New NM discussion thread:
Beyond MAC randomization (prevent tracking)
https://mail.gnome.org/archives/networkmanager-list/2017-April/msg00032.html
tasket
commented
Apr 26, 2017
|
New NM discussion thread: Beyond MAC randomization (prevent tracking) |
added a commit
that referenced
this issue
Apr 28, 2017
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
mfc
Aug 4, 2017
Member
hey all, given F25 is now the current template with Qubes 4.0 which comes with NetworkManager 1.4.4, I would propose implementing the basic version outlined in the docs be the default for new installations.
It is scan with random MAC address, use a stable MAC address otherwise:
[device]
wifi.scan-rand-mac-address=yes
[connection]
wifi.cloned-mac-address=stable
ethernet.cloned-mac-address=stable
Once implemented, I think we can close this ticket and discuss further strategies for local network privacy in #2361.
|
hey all, given F25 is now the current template with Qubes 4.0 which comes with It is scan with random MAC address, use a stable MAC address otherwise: Once implemented, I think we can close this ticket and discuss further strategies for local network privacy in #2361. |
added a commit
that referenced
this issue
Aug 5, 2017
andrewdavidwong
referenced this issue
in QubesOS/qubes-doc
Mar 1, 2018
Merged
anonymizing-your-mac-address version notes #607
andrewdavidwong
referenced this issue
May 18, 2018
Closed
MAC address randomization failure (user error almost certain) #3905
andrewdavidwong
referenced this issue
May 26, 2018
Open
"Anonymizing your MAC Address" fails for ens6/wired device. #3928
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
andrewdavidwong
May 26, 2018
Member
Closing this as "done," per #938 (comment) and #3905 (comment). If you believe the issue is not yet done, or if anyone is still affected by this issue, please leave a comment, and we'll be happy to reopen this. Thank you.
|
Closing this as "done," per #938 (comment) and #3905 (comment). If you believe the issue is not yet done, or if anyone is still affected by this issue, please leave a comment, and we'll be happy to reopen this. Thank you. |
marmarek commentedMar 8, 2015
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:
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