[kernel-hardening] Patch for random mac address

[kernel-hardening] Patch for random mac address

[HacKurx]

[-- Attachment #1: Type: text/plain, Size: 607 bytes --]

Hi all,

Firstly, I am sad that no major company has taken the trouble to
finance PaX / Grsecurity so they can continue their development in a
way that is accessible to all. This is regrettable because their work
is your main source of inspiration ...

In what brings me here. Brad had released an interesting hack for privacy:
https://www.grsecurity.net/~spender/random_mac.diff

I updated this patch and added a menu option. Can you examine it for
include it upstream?
Because this would be useful for distributions like Tails, Subgraph
OS, Kali Linux and other ...

Thanks. Best regards,

HacKurx (Loic)

[-- Attachment #2: random-mac_linux-4.12-rc2.diff --]
[-- Type: text/plain, Size: 2039 bytes --]

diff --git a/net/core/dev.c b/net/core/dev.c
index fca407b..3eeb42b 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -6669,6 +6669,26 @@ int dev_change_flags(struct net_device *dev, unsigned int flags)
 
 	changes = (old_flags ^ dev->flags) | (old_gflags ^ dev->gflags);
 	__dev_notify_flags(dev, old_flags, changes);
+
+#ifdef CONFIG_RANDOM_MAC_ADDRESS
+	if ((changes & IFF_UP) && !(old_flags & IFF_UP)) {
+		/* randomize MAC whenever interface is brought up */
+		struct sockaddr sa;
+		unsigned int mac4;
+		unsigned short mac2;
+
+		mac4 = prandom_u32();
+		mac2 = prandom_u32();
+		memcpy(sa.sa_data, &mac4, sizeof(mac4));
+		memcpy((char *)sa.sa_data + sizeof(mac4), &mac2, sizeof(mac2));
+		if (!is_valid_ether_addr(sa.sa_data))
+			sa.sa_data[5] = 1;
+		sa.sa_data[0] &= 0xFC;
+		sa.sa_family = dev->type;
+		dev_set_mac_address(dev, &sa);
+	}
+#endif
+
 	return ret;
 }
 EXPORT_SYMBOL(dev_change_flags);
diff --git a/net/core/dev_ioctl.c b/net/core/dev_ioctl.c
index b94b1d2..b020d15 100644
--- a/net/core/dev_ioctl.c
+++ b/net/core/dev_ioctl.c
@@ -262,6 +262,10 @@ static int dev_ifsioc(struct net *net, struct ifreq *ifr, unsigned int cmd)
 
 	case SIOCSIFHWADDR:
 		return dev_set_mac_address(dev, &ifr->ifr_hwaddr);
+#ifdef CONFIG_RANDOM_MAC_ADDRESS
+		/* ignore userland MAC changes */
+		return 0;
+#endif
 
 	case SIOCSIFHWBROADCAST:
 		if (ifr->ifr_hwaddr.sa_family != dev->type)
diff --git a/security/Kconfig b/security/Kconfig
index 93027fd..6b7b6fc 100644
--- a/security/Kconfig
+++ b/security/Kconfig
@@ -67,6 +67,14 @@ config SECURITY_NETWORK_XFRM
 	  IPSec.
 	  If you are unsure how to answer this question, answer N.
 
+config RANDOM_MAC_ADDRESS
+	bool "Use random MAC adresses"
+	default n
+	help
+	  Say Y here for randomize the MAC addresses of network interfaces.
+	  This option is recommended for people who want to increase their privacy.
+	  If you are unsure how to answer this question, answer N.
+
 config SECURITY_PATH
 	bool "Security hooks for pathname based access control"
 	depends on SECURITY

Re: [kernel-hardening] Patch for random mac address

[Casey Schaufler]

On 5/24/2017 1:44 PM, HacKurx wrote:
> Hi all,
>
> Firstly, I am sad that no major company has taken the trouble to
> finance PaX / Grsecurity so they can continue their development in a
> way that is accessible to all. This is regrettable because their work
> is your main source of inspiration ...
>
> In what brings me here. Brad had released an interesting hack for privacy:
> https://www.grsecurity.net/~spender/random_mac.diff
>
> I updated this patch and added a menu option. Can you examine it for
> include it upstream?
> Because this would be useful for distributions like Tails, Subgraph
> OS, Kali Linux and other ...
>
> Thanks. Best regards,
>
> HacKurx (Loic)

Please submit patches inline for review.

Re: [kernel-hardening] Patch for random mac address

[Lukas Odzioba]

2017-05-25 0:40 GMT+02:00 Casey Schaufler <casey@schaufler-ca.com>:
>
> @@ -262,6 +262,10 @@ static int dev_ifsioc(struct net *net, struct ifreq *ifr, unsigned int cmd)
>
>  case SIOCSIFHWADDR:
>  return dev_set_mac_address(dev, &ifr->ifr_hwaddr);
> +#ifdef CONFIG_RANDOM_MAC_ADDRESS
> + /* ignore userland MAC changes */
> + return 0;
> +#endif

I am not sure whether this code does what the comment advertises, but
I bet that Kali-like distro users still would like to be able to
change MAC, also such behavior should be documented in config section.
Thank you for your involvement, please take a look at this article
about preparing kernel patches in general (besides ml addresses most
of it could apply here as well):
https://www.kernel.org/doc/html/latest/process/submitting-patches.html

Thanks,
Lukas

Re: [kernel-hardening] Patch for random mac address

[intrigeri]

Hi,

HacKurx:
> Because this would be useful for distributions like Tails, Subgraph
> OS, Kali Linux and other ...

For what it's worth, it's unlikely that Tails ever uses this unless it
can be controlled at runtime from userspace: we need to give users an
option to disable MAC address randomization, because it breaks network
connectivity in some cases.

Cheers,
-- 
intrigeri

Re: [kernel-hardening] Patch for random mac address

[Rik van Riel]

[-- Attachment #1: Type: text/plain, Size: 734 bytes --]

On Thu, 2017-05-25 at 09:31 +0200, intrigeri wrote:
> Hi,
> 
> HacKurx:
> > Because this would be useful for distributions like Tails, Subgraph
> > OS, Kali Linux and other ...
> 
> For what it's worth, it's unlikely that Tails ever uses this unless
> it
> can be controlled at runtime from userspace: we need to give users an
> option to disable MAC address randomization, because it breaks
> network
> connectivity in some cases.

That suggests maybe this kind of functionality should
be implemented in userspace, instead?

Maybe in NetworkManager, or whatever Tails uses to
manage the network. After all, setting the MAC address
to something else is already supported by the kernel...

-- 
All rights reversed

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [kernel-hardening] Patch for random mac address

[intrigeri]

Rik van Riel:
> That suggests maybe this kind of functionality should
> be implemented in userspace, instead?

> Maybe in NetworkManager, […]

It's already implemented in NetworkManager :)

Cheers,
-- 
intrigeri

Re: [kernel-hardening] Patch for random mac address

[Theodore Ts'o]

On Thu, May 25, 2017 at 09:31:15AM +0200, intrigeri wrote:
> 
> HacKurx:
> > Because this would be useful for distributions like Tails, Subgraph
> > OS, Kali Linux and other ...
> 
> For what it's worth, it's unlikely that Tails ever uses this unless it
> can be controlled at runtime from userspace: we need to give users an
> option to disable MAC address randomization, because it breaks network
> connectivity in some cases.

BTW, in case people aren't aware ---- you can set the MAC address from
userspace already:

Package: macchanger
Source: macchanger (1.7.0-5.3)
Version: 1.7.0-5.3+b1
Installed-Size: 636
Maintainer: David Paleino <dapal@debian.org>
Architecture: amd64
Depends: libc6 (>= 2.4), debconf (>= 0.5) | debconf-2.0, dpkg (>= 1.15.4) | install-info
Description-en: utility for manipulating the MAC address of network interfaces
 GNU MAC Changer is an utility that makes the maniputation of MAC addresses of
 network interfaces easier.  MAC addresses are unique identifiers on networks,
 they only need to be unique, they can be changed on most network hardware.
 MAC addresses have started to be abused by unscrupulous marketing firms,
 government agencies, and others to provide an easy way to track a computer
 across multiple networks.  By changing the MAC address regularly, this kind
 of tracking can be thwarted, or at least made a lot more difficult.
 .
 Features:
 .
   * set specific MAC address of a network interface
   * set the MAC randomly
   * set a MAC of another vendor
   * set another MAC of the same vendor
   * set a MAC of the same kind (eg: wireless card)
   * display a vendor MAC list (today, 6200 items) to choose from
Description-md5: b3958cf2d904ea6ecdbefc5cd46ec519
Homepage: https://github.com/alobbs/macchanger
Tag: network::configuration, role::program, scope::utility, suite::gnu,
 use::configuring
Section: net
Priority: extra
Filename: pool/main/m/macchanger/macchanger_1.7.0-5.3+b1_amd64.deb
Size: 192768
MD5sum: 35c51e01c0d778961eeda48faf4d884f
SHA256: 00cc5c1e6f2af37023315e5bb1473d3293acfdbf61fb4515c0cb094789d44147

Re: [kernel-hardening] Patch for random mac address

[Rik van Riel]

[-- Attachment #1: Type: text/plain, Size: 405 bytes --]

On Thu, 2017-05-25 at 17:47 +0200, intrigeri wrote:
> Rik van Riel:
> > That suggests maybe this kind of functionality should
> > be implemented in userspace, instead?
> > Maybe in NetworkManager, […]
> 
> It's already implemented in NetworkManager :)

So this kernel patch does not solve any problem,
because the solution has already been implemented
in userspace?

-- 
All rights reversed

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [kernel-hardening] Patch for random mac address

[Kees Cook]

On Thu, May 25, 2017 at 8:59 AM, Rik van Riel <riel@redhat.com> wrote:
> On Thu, 2017-05-25 at 17:47 +0200, intrigeri wrote:
>> Rik van Riel:
>> > That suggests maybe this kind of functionality should
>> > be implemented in userspace, instead?
>> > Maybe in NetworkManager, […]
>>
>> It's already implemented in NetworkManager :)
>
> So this kernel patch does not solve any problem,
> because the solution has already been implemented
> in userspace?

It makes sure you can never not randomize the MAC, no matter what
userspace is doing. I'm not opposed to the idea, but it feels like
overkill to me.

BTW, the proposed patch is slightly wrong: it still allows userspace
to change the MAC address. The ifdef with the return 0 should be moved
up (and "return 0" seems like a bit of a lie: maybe -EINVAL or
-ENOTSUPPORTED?). How about sending a v2 with that fixed, inline, etc.
And see if other people chime in?

It might also be nice to have it be a kernel command line option as
well as a Kconfig, so that distros could include the Kconfig but not
enable it by default (interested users could set the command line
option to enable it).

Thanks!

-Kees

-- 
Kees Cook
Pixel Security

Re: [kernel-hardening] Patch for random mac address

[Anisse Astier]

Hi,

On Thu, May 25, 2017 at 10:28:19AM -0700, Kees Cook wrote:
> On Thu, May 25, 2017 at 8:59 AM, Rik van Riel <riel@redhat.com> wrote:
> > On Thu, 2017-05-25 at 17:47 +0200, intrigeri wrote:
> >> Rik van Riel:
> >> > That suggests maybe this kind of functionality should
> >> > be implemented in userspace, instead?
> >> > Maybe in NetworkManager, […]
> >>
> >> It's already implemented in NetworkManager :)
> >
> > So this kernel patch does not solve any problem,
> > because the solution has already been implemented
> > in userspace?
> 
> It makes sure you can never not randomize the MAC, no matter what
> userspace is doing. I'm not opposed to the idea, but it feels like
> overkill to me.
> 
> BTW, the proposed patch is slightly wrong: it still allows userspace
> to change the MAC address. The ifdef with the return 0 should be moved
> up (and "return 0" seems like a bit of a lie: maybe -EINVAL or
> -ENOTSUPPORTED?). How about sending a v2 with that fixed, inline, etc.
> And see if other people chime in?

Yes, the original grsec patch is slightly different.

> 
> It might also be nice to have it be a kernel command line option as
> well as a Kconfig, so that distros could include the Kconfig but not
> enable it by default (interested users could set the command line
> option to enable it).

Since it's still on the table, there's already a facility in the kernel
to generate a random mac in include/linux/etherdevice.h:
eth_random_addr. It's used by most network drivers when they can't fetch
the hardware address, so that there's still a functionning interface.

I'd be curious to know why this patch does not use it. The generation
looks slightly similar.

Regards,

Anisse Astier

Re: [kernel-hardening] Patch for random mac address

[HacKurx]

[-- Attachment #1: Type: text/plain, Size: 1367 bytes --]

2017-05-25 19:28 GMT+02:00 Kees Cook <keescook@chromium.org>:
> On Thu, May 25, 2017 at 8:59 AM, Rik van Riel <riel@redhat.com> wrote:
>> On Thu, 2017-05-25 at 17:47 +0200, intrigeri wrote:
>>> Rik van Riel:
>>> > That suggests maybe this kind of functionality should
>>> > be implemented in userspace, instead?
>>> > Maybe in NetworkManager, […]
>>>
>>> It's already implemented in NetworkManager :)
>>
>> So this kernel patch does not solve any problem,
>> because the solution has already been implemented
>> in userspace?
>
> It makes sure you can never not randomize the MAC

You have perfectly understood.

> BTW, the proposed patch is slightly wrong: it still allows userspace
> to change the MAC address.

This is not the most important because it is already another MAC
address because this patch randomize MAC whenever interface is brought
up.

> The ifdef with the return 0 should be moved
> up (and "return 0" seems like a bit of a lie: maybe -EINVAL or
> -ENOTSUPPORTED?).
-EINVAL seems to be a good idea, I will use it to never reveal the
permanent MAC address.

> How about sending a v2 with that fixed, inline, etc.

Agree with the V2. I'm not a developer, what do you mean by inline? Send by GIT?
If someone can make him grow in my place I will pay him a beer ^^

Thank you all. Best regards,

HacKurx (Loic)

[-- Attachment #2: random-mac_linux-4.12-rc2_v2.diff --]
[-- Type: text/plain, Size: 1934 bytes --]

diff --git a/net/core/dev.c b/net/core/dev.c
index fca407b..3eeb42b 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -6669,6 +6669,26 @@ int dev_change_flags(struct net_device *dev, unsigned int flags)
 
 	changes = (old_flags ^ dev->flags) | (old_gflags ^ dev->gflags);
 	__dev_notify_flags(dev, old_flags, changes);
+
+#ifdef CONFIG_RANDOM_MAC_ADDRESS
+	if ((changes & IFF_UP) && !(old_flags & IFF_UP)) {
+		/* randomize MAC whenever interface is brought up */
+		struct sockaddr sa;
+		unsigned int mac4;
+		unsigned short mac2;
+
+		mac4 = prandom_u32();
+		mac2 = prandom_u32();
+		memcpy(sa.sa_data, &mac4, sizeof(mac4));
+		memcpy((char *)sa.sa_data + sizeof(mac4), &mac2, sizeof(mac2));
+		if (!is_valid_ether_addr(sa.sa_data))
+			sa.sa_data[5] = 1;
+		sa.sa_data[0] &= 0xFC;
+		sa.sa_family = dev->type;
+		dev_set_mac_address(dev, &sa);
+	}
+#endif
+
 	return ret;
 }
 EXPORT_SYMBOL(dev_change_flags);
diff --git a/net/core/dev_ioctl.c b/net/core/dev_ioctl.c
index b94b1d2..b020d15 100644
--- a/net/core/dev_ioctl.c
+++ b/net/core/dev_ioctl.c
@@ -463,7 +463,12 @@
 					 sizeof(struct ifreq)))
 				ret = -EFAULT;
 		}
+#ifdef CONFIG_RANDOM_MAC_ADDRESS
+		/* Don't reveal the permanent MAC address */
+		return -EINVAL;
+#else
 		return ret;
+#endif
 
 	/*
 	 *	These ioctl calls:
diff --git a/security/Kconfig b/security/Kconfig
index 93027fd..6b7b6fc 100644
--- a/security/Kconfig
+++ b/security/Kconfig
@@ -67,6 +67,14 @@ config SECURITY_NETWORK_XFRM
 	  IPSec.
 	  If you are unsure how to answer this question, answer N.
 
+config RANDOM_MAC_ADDRESS
+	bool "Use random MAC adresses"
+	default n
+	help
+	  Say Y here for randomize the MAC addresses of network interfaces.
+	  This option is recommended for people who want to increase their privacy.
+	  If you are unsure how to answer this question, answer N.
+
 config SECURITY_PATH
 	bool "Security hooks for pathname based access control"
 	depends on SECURITY

Re: [kernel-hardening] Patch for random mac address

[Daniel Micay]

On Thu, 2017-05-25 at 23:28 +0200, Anisse Astier wrote:
> Hi,
> 
> On Thu, May 25, 2017 at 10:28:19AM -0700, Kees Cook wrote:
> > On Thu, May 25, 2017 at 8:59 AM, Rik van Riel <riel@redhat.com>
> > wrote:
> > > On Thu, 2017-05-25 at 17:47 +0200, intrigeri wrote:
> > > > Rik van Riel:
> > > > > That suggests maybe this kind of functionality should
> > > > > be implemented in userspace, instead?
> > > > > Maybe in NetworkManager, […]
> > > > 
> > > > It's already implemented in NetworkManager :)
> > > 
> > > So this kernel patch does not solve any problem,
> > > because the solution has already been implemented
> > > in userspace?
> > 
> > It makes sure you can never not randomize the MAC, no matter what
> > userspace is doing. I'm not opposed to the idea, but it feels like
> > overkill to me.
> > 
> > BTW, the proposed patch is slightly wrong: it still allows userspace
> > to change the MAC address. The ifdef with the return 0 should be
> > moved
> > up (and "return 0" seems like a bit of a lie: maybe -EINVAL or
> > -ENOTSUPPORTED?). How about sending a v2 with that fixed, inline,
> > etc.
> > And see if other people chime in?
> 
> Yes, the original grsec patch is slightly different.

It was never included in grsecurity, so it's not really a grsecurity
patch.

Re: [kernel-hardening] Patch for random mac address

[Anisse Astier]

On Fri, May 26, 2017 at 09:55:37AM +0200, HacKurx wrote:
> 2017-05-25 19:28 GMT+02:00 Kees Cook <keescook@chromium.org>:
> > How about sending a v2 with that fixed, inline, etc.
> 
> Agree with the V2. I'm not a developer, what do you mean by inline? Send by GIT?
> If someone can make him grow in my place I will pay him a beer ^^

What he meant, is to follow the kernel process for sending patches.
Lukas already sent a link to the documentation, but you may be
interested in these parts:
https://www.kernel.org/doc/html/latest/process/submitting-patches.html#no-mime-no-links-no-compression-no-attachments-just-plain-text
Yes, you can use git as a client (with git send-email), but it's not
mandatory. You should use your real name though:
https://www.kernel.org/doc/html/latest/process/submitting-patches.html#sign-your-work-the-developer-s-certificate-of-origin

And add a Signed-off-by line.


> 
> Thank you all. Best regards,
> 
> HacKurx (Loic)

> diff --git a/net/core/dev.c b/net/core/dev.c
> index fca407b..3eeb42b 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -6669,6 +6669,26 @@ int dev_change_flags(struct net_device *dev, unsigned int flags)
>  
>  	changes = (old_flags ^ dev->flags) | (old_gflags ^ dev->gflags);
>  	__dev_notify_flags(dev, old_flags, changes);
> +
> +#ifdef CONFIG_RANDOM_MAC_ADDRESS
> +	if ((changes & IFF_UP) && !(old_flags & IFF_UP)) {
> +		/* randomize MAC whenever interface is brought up */
> +		struct sockaddr sa;
> +		unsigned int mac4;
> +		unsigned short mac2;
> +
> +		mac4 = prandom_u32();
> +		mac2 = prandom_u32();
> +		memcpy(sa.sa_data, &mac4, sizeof(mac4));
> +		memcpy((char *)sa.sa_data + sizeof(mac4), &mac2, sizeof(mac2));
> +		if (!is_valid_ether_addr(sa.sa_data))
> +			sa.sa_data[5] = 1;
> +		sa.sa_data[0] &= 0xFC;
> +		sa.sa_family = dev->type;
> +		dev_set_mac_address(dev, &sa);

You didn't answer my question regarding why this is different from the
function eth_random_addr.

Regards,

Anisse

Re: [kernel-hardening] Patch for random mac address

[HacKurx]

2017-05-26 14:34 GMT+02:00 Anisse Astier <anisse@astier.eu>:
> On Fri, May 26, 2017 at 09:55:37AM +0200, HacKurx wrote:
>> 2017-05-25 19:28 GMT+02:00 Kees Cook <keescook@chromium.org>:
>> > How about sending a v2 with that fixed, inline, etc.
>>
>> Agree with the V2. I'm not a developer, what do you mean by inline? Send by GIT?
>> If someone can make him grow in my place I will pay him a beer ^^
>
> What he meant, is to follow the kernel process for sending patches.
> Lukas already sent a link to the documentation, but you may be
> interested in these parts:
> https://www.kernel.org/doc/html/latest/process/submitting-patches.html#no-mime-no-links-no-compression-no-attachments-just-plain-text
> Yes, you can use git as a client (with git send-email), but it's not
> mandatory. You should use your real name though:
> https://www.kernel.org/doc/html/latest/process/submitting-patches.html#sign-your-work-the-developer-s-certificate-of-origin
>
> And add a Signed-off-by line.

I didn't understand it all that well. English is not my native language.

In your link I could see:
"Gmail (Web GUI)
Does not work for sending patches.
Gmail web client converts tabs to spaces automatically.
At the same time it wraps lines every 78 chars with CRLF style line
breaks although tab2space problem can be solved with external editor.
Another problem is that Gmail will base64-encode any message that has
a non-ASCII character. That includes things like European names."

So here is my error ^^

>> diff --git a/net/core/dev.c b/net/core/dev.c
>> index fca407b..3eeb42b 100644
>> --- a/net/core/dev.c
>> +++ b/net/core/dev.c
>> @@ -6669,6 +6669,26 @@ int dev_change_flags(struct net_device *dev, unsigned int flags)
>>
>>       changes = (old_flags ^ dev->flags) | (old_gflags ^ dev->gflags);
>>       __dev_notify_flags(dev, old_flags, changes);
>> +
>> +#ifdef CONFIG_RANDOM_MAC_ADDRESS
>> +     if ((changes & IFF_UP) && !(old_flags & IFF_UP)) {
>> +             /* randomize MAC whenever interface is brought up */
>> +             struct sockaddr sa;
>> +             unsigned int mac4;
>> +             unsigned short mac2;
>> +
>> +             mac4 = prandom_u32();
>> +             mac2 = prandom_u32();
>> +             memcpy(sa.sa_data, &mac4, sizeof(mac4));
>> +             memcpy((char *)sa.sa_data + sizeof(mac4), &mac2, sizeof(mac2));
>> +             if (!is_valid_ether_addr(sa.sa_data))
>> +                     sa.sa_data[5] = 1;
>> +             sa.sa_data[0] &= 0xFC;
>> +             sa.sa_family = dev->type;
>> +             dev_set_mac_address(dev, &sa);
>
> You didn't answer my question regarding why this is different from the
> function eth_random_addr.

Because it's been working for years and I'm not a developer / kernel expert.
"Keep it stupidly simple" Might be a reason?

-- 
Best regards,

HacKurx (Loic)
blog.opensec.fr

Re: [kernel-hardening] Patch for random mac address

[HacKurx]

[-- Attachment #1: Type: text/plain, Size: 1692 bytes --]

Le 26/05/2017 à 14:34, Anisse Astier a écrit :
> On Fri, May 26, 2017 at 09:55:37AM +0200, HacKurx wrote:
>> diff --git a/net/core/dev.c b/net/core/dev.c
>> index fca407b..3eeb42b 100644
>> --- a/net/core/dev.c
>> +++ b/net/core/dev.c
>> @@ -6669,6 +6669,26 @@ int dev_change_flags(struct net_device *dev, unsigned int flags)
>>  
>>  	changes = (old_flags ^ dev->flags) | (old_gflags ^ dev->gflags);
>>  	__dev_notify_flags(dev, old_flags, changes);
>> +
>> +#ifdef CONFIG_RANDOM_MAC_ADDRESS
>> +	if ((changes & IFF_UP) && !(old_flags & IFF_UP)) {
>> +		/* randomize MAC whenever interface is brought up */
>> +		struct sockaddr sa;
>> +		unsigned int mac4;
>> +		unsigned short mac2;
>> +
>> +		mac4 = prandom_u32();
>> +		mac2 = prandom_u32();
>> +		memcpy(sa.sa_data, &mac4, sizeof(mac4));
>> +		memcpy((char *)sa.sa_data + sizeof(mac4), &mac2, sizeof(mac2));
>> +		if (!is_valid_ether_addr(sa.sa_data))
>> +			sa.sa_data[5] = 1;
>> +		sa.sa_data[0] &= 0xFC;
>> +		sa.sa_family = dev->type;
>> +		dev_set_mac_address(dev, &sa);
> You didn't answer my question regarding why this is different from the
> function eth_random_addr.
What do you think by replacing the whole by that?

+#ifdef CONFIG_RANDOM_MAC_ADDRESS
+    /* randomize MAC whenever interface is brought up */
+    if ((changes & IFF_UP) && !(old_flags & IFF_UP)) {
+        struct sockaddr sa;
+        eth_random_addr(sa.sa_data);
+        sa.sa_family = dev->type;
+        dev_set_mac_address(dev, &sa);

The network doesn't work with "eth_hw_addr_random(dev);" (the change of MAC addresses works well). Do you know why ?
Because the eth_hw_addr_randomfunction works better on all types of network cards.

Thanks,

Loic

[-- Attachment #2: Type: text/html, Size: 2681 bytes --]

Re: [kernel-hardening] Patch for random mac address

[Anisse Astier]

On Fri, Jun 09, 2017 at 02:00:37PM +0200, HacKurx wrote:
> Le 26/05/2017 à 14:34, Anisse Astier a écrit :
> > You didn't answer my question regarding why this is different from the
> > function eth_random_addr.
> What do you think by replacing the whole by that?
> 
> +#ifdef CONFIG_RANDOM_MAC_ADDRESS
> +    /* randomize MAC whenever interface is brought up */
> +    if ((changes & IFF_UP) && !(old_flags & IFF_UP)) {
> +        struct sockaddr sa;
> +        eth_random_addr(sa.sa_data);
> +        sa.sa_family = dev->type;
> +        dev_set_mac_address(dev, &sa);

Yes, I meant something like that.

> 
> The network doesn't work with "eth_hw_addr_random(dev);" (the change of MAC addresses works well). Do you know why ?

I think that's because eth_hw_addr_random() is meant to be called by the
driver. Your solution is simpler, although it doesn't set
addr_assign_type to NET_ADDR_RANDOM, athough this field seems to be used
erratically (some use it as bitfield, but it does not look like one).

> Because the eth_hw_addr_randomfunction works better on all types of network cards.

You mean eth_random_addr, correct ?

Regards,

Anisse

Re: [kernel-hardening] Patch for random mac address

[Matt Brown]

On 5/25/17 11:48 AM, Theodore Ts'o wrote:
> On Thu, May 25, 2017 at 09:31:15AM +0200, intrigeri wrote:
>>
>> HacKurx:
>>> Because this would be useful for distributions like Tails, Subgraph
>>> OS, Kali Linux and other ...
>>
>> For what it's worth, it's unlikely that Tails ever uses this unless it
>> can be controlled at runtime from userspace: we need to give users an
>> option to disable MAC address randomization, because it breaks network
>> connectivity in some cases.
> 
> BTW, in case people aren't aware ---- you can set the MAC address from
> userspace already:
> 
> Package: macchanger


Yeah I've used this program before. If you want it to always run at boot
you can write a service script for your init system of choice and set it
to run on start up.

In what way does this patch protect you more than a start up script as
described above?

Matt

Re: [kernel-hardening] Patch for random mac address

[HacKurx]

Le 09/06/2017 à 15:11, Matt Brown a écrit :

> On 5/25/17 11:48 AM, Theodore Ts'o wrote:
>> On Thu, May 25, 2017 at 09:31:15AM +0200, intrigeri wrote:
>>> HacKurx:
>>>> Because this would be useful for distributions like Tails, Subgraph
>>>> OS, Kali Linux and other ...
>>> For what it's worth, it's unlikely that Tails ever uses this unless it
>>> can be controlled at runtime from userspace: we need to give users an
>>> option to disable MAC address randomization, because it breaks network
>>> connectivity in some cases.
>> BTW, in case people aren't aware ---- you can set the MAC address from
>> userspace already:
>>
>> Package: macchanger
>
> Yeah I've used this program before. If you want it to always run at boot
> you can write a service script for your init system of choice and set it
> to run on start up.
>
> In what way does this patch protect you more than a start up script as
> described above?
>
> Matt
Because macchanger use the kernel...
It is loaded too late and increases the risk of the MAC address does not change. See:
https://github.com/alobbs/macchanger/issues

Does your startup script depend on systemd? Who it depends on udev and recommend dbus ...
Is the permanent MAC address stored in the system logs (boot, ipv6, firewall) ?
If a user use journalctl under ubuntu he could see this without sudo ...

For me randomize MAC in a kernel is be the best method to do this.

Loic