Hi,
Daniel Kahn Gillmor:
> fwiw, i prefer mac address spoofing at the udev layer since it means the
> first userspace tool to see the device gets a chance to set the mac
> address immediately.
Sure, this way of doing things provides better guarantees than
a NM-based approach. But I think it will
On Fri 2016-08-26 14:50:12 -0400, intrigeri wrote:
> Since then, NetworkManager gained the ability to randomize MAC
> addresses [1]. If we delegate the bulk of the work to it, then this
> becomes:
>
> a) We remove the modules blacklist logic.
> b) We set up a boot-time firewall that blocks all
Hi,
intrigeri:
> anonym wrote (22 Dec 2015 16:21:50 GMT) :
>> Patrick Schleizer:
>>> Wouldn't it be possible, and simpler, to block all networking with
>>> iptables to prevent early MAC leaks so kernel module blacklisting could
>>> be avoided?
> After spending hours hunting down #9012 today, I
Hi,
[not Cc'ing other mailing-lists because 1. what I'm going to discuss
has little to do with the initial request, and is mostly
Tails -specific; 2. I don't fancy cross-posting entire discussions.
Let's report back to the other lists once we've reached some kind of
conclusion here.]
anonym
[Sorry for the delay :S]
Patrick Schleizer:
> I understand Tails' MAC 'leak prevention' [1] [2] as this... Without
> 'leak prevention', things would happen like this:
>
> a)
>
> 1) system boots
> 2) kernel module loaded
> 3) MAC leaked
> 4) macchanger started
> 5) MAC changed
> 6)
On Wed, Nov 25, 2015 at 11:09:32PM +, Patrick Schleizer wrote:
> I understand Tails' MAC 'leak prevention' [1] [2] as this... Without
> 'leak prevention', things would happen like this:
>
> a)
>
> 1) system boots
> 2) kernel module loaded
> 3) MAC leaked
> 4) macchanger started
> 5) MAC
