MAC randomization breaks root server and VirtualBox DHCP / IPv6PrivacyExtensions might be problematic

[adrelanos]

https://github.com/Kicksecure/security-misc/blob/master/usr/lib/NetworkManager/conf.d/80_randomize-mac.conf

[device-mac-randomization]
wifi.scan-rand-mac-address=yes

[connection-mac-randomization]
ethernet.cloned-mac-address=random
wifi.cloned-mac-address=random

1. Breaks root servers, namely broke kicksecure.com. This is what the server provide sent by e-mail.

We have detected that your server is using different MAC addresses from those allowed by your Robot account.

Please take all necessary measures to avoid this in the future and to solve the issue.
We also request that you send a short response to us. This response should contain information about how this could have happened and what you intend to do about it.
In the event that the following steps are not completed successfully, your server can be locked at any time after 2024-01-17 16:51:11 +0100.

How to proceed:
- Solve the issue
- Please note, in case you have fixed the problem, please wait at least 10 minutes before rechecking: ...
- After successfully testing that the issue is resolved, send us a statement by using the following link:...

Please visit our FAQ here, if you are unsure how to proceed:
https://docs.hetzner.com/robot/dedicated-server/faq/error-faq/#mac-errors

Important note:
When replying to us, please leave the abuse ID [...] unchanged in the subject line. Manual replies will only be handled in the event of a lock.
Please note that we do not provide telephone support in our department. If you have any questions, please send them to us by responding to this email.

Kind regards

Network department

2. Breaks VirtualBox DHCP when using Network Manger (in Kicksecure) after VM reboot (sudo reboot). It is functional for the first start after powering off and powering on the VM. [1]

Might be related:
https://forums.virtualbox.org/viewtopic.php?t=86753

Could be a Network Manager issue:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1116421
https://askubuntu.com/questions/307717/networkmanager-problem-with-cloned-mac-address

---

[1] Before someone says that's a VirtualBox issue, no, I mean, maybe, but that doesn't matter.
VirtualBox is a valid environment. If that breaks, other environments will break as well.
Broken networking is extremely frustrating. MAC randomization would be suitable for Kicksecure, but only if stable.

It's not important enough to break common network configurations in common environments.

---

TODO: This bug has to be reported to Network Manager (NM) as above bug reports apparently never have reached upstream NM.

[adrelanos]

Therefore disabled just now in git.

[adrelanos]

By the same logic I am also reverting IPv6PrivacyExtensions.

It's all nice and dandy for end-users but on servers this can break connectivity to the level that SSH access is no longer possible. Recovering from this isn't trivial.

[monsieuremre]

For the first problem: The error seems to originate from a hetzner server. So, it is a server. Randomizing the mac address on a server can break many things, in some cases certainly. It is also not a great security or pactice to randomize mac addresses per connection or use the privacy extensions, because, it won't bring any benefits on a server, firstly. And also, it might even be less secure due to unexpected behavior, but I cannot really comment on that one.

I don't think this problem is relevant at all tho. I was under the impression that Kicksecure is strictly a desktop operating system.

The second one: I am not sure what kind of effects this might have when virtualizing. Especially with whonix, where there are two machines and only one of them really connects to the internet. But I am pretty sure this should not be a problem at all. Which as I see, it isn't 'normally'. Curious how it only happens after reboot within the machine. This can probably be fixed if we find the cause.

I have a guess. There is a way to check your original mac address and the spoofed mac address. Does the 'original' mac address change after sudo reboot? I think you can check it with ip link show near permaddr. If it does change, that is the problem. But there is no reason that would happen too. Also providing logs on the breakage might help to identify the issue.

[adrelanos]

I was under the impression that Kicksecure is strictly a desktop operating system.

No. For years (at least since Whonix for VirtualBox with CLI was released), I always made sure to structure the code so it can easily be used without a desktop environment. And don't hardcode a desktop environment. So contributors can in theory add support for other desktop environments.
https://www.kicksecure.com/wiki/Other_Desktop_Environments
(This is only possible if packages are cleanly separated into GUI and CLI.)

At time of writing, Kicksecure on top of Debian installation instructions contain CLI, there's instructions for chroot.

But there might be some contributed texts in the wiki that looked fine but said "desktop" which didn't come to my attention yet. Fixed some just now:
https://www.kicksecure.com/w/index.php?title=About&curid=2242&diff=79224&oldid=79198

Curious how it only happens after reboot within the machine.

Because only then the config is reload. We didn't have code

Does the 'original' mac address change after sudo reboot?

Yes. Since I attempted several reboots before, I got an e-mail with the different rejected random MAC address every time.

If it does change, that is the problem.

Isn't that was MAC randomization does?

Also providing logs on the breakage might help to identify the issue.

There are none. And that's not a good environment for experimentation as this triggers the abuse handling team.

[monsieuremre]

Ok I feel like I didn't make my points clear. Being able to run headless has nothing to do with being a desktop operating system. A headless kicksecure possible and this mac randomization won't break it, if it is on a desktop system, or a workstaton, whatever you want to call it. Being a server is being a server. Servers have static ip addresses and stuff and they need to be reliable in terms of connections. Randomizing mac addresses or using privacy extensions on a server is useless because in a server, these things are meant to be public in a sense and not changing. And this is completely unrealted to running kicksecure headless, or with CLI as you called it, on desktop.

Isn't that was MAC randomization does?
No. I wasn't clear here also probably. I said, when you run the command, you see two mac addresses. One is your mac address now on the network. That is the randomized one. And next to that, you see something called a permaddr. This is the original address that we would use if we didn't randomize it. This is tied to hardware and does not change. This information is not made public to the network when we are randomizing, the randomized one is shown. Which you can also see there when running the command to check your mac address.

So I ask once again, does the 'original' mac address change after sudo reboot? I mean the permaddr. It probably does not, but I think maybe it is somehow false on reboot because of some cache thing. This is pure speculation by the way, I don't know the reason, this is just my guesswork.

[adrelanos]

By server I mean server. kicksecure.com itself runs Kicksecure.

Kicksecure is supposed to run on servers too. All. Headless, server, all use cases. All that Kicksecure does shouldn't break any of Debian's functionality more than absolutely necessary. Hence deskop, server, headless, cli, chroot, VM, ISO, however it is called should all be supported.

Randomizing mac addresses or using privacy extensions on a server is useless because in a server, these things are meant to be public in a sense and not changing.

Right. Not only useless but also breaking connectivity / SSH login. Hence, reverted (commented out) in git.

So I ask once again, does the 'original' mac address change after sudo reboot? I mean the permaddr. It probably does not,

It probably did not change. Because what I can tell with certainty that once I suspected it MAC randomization broke networking, that I successfully restored server connectivity by deleting these config files followed by a reboot.

If MAC address was still customized (randomized) after deleting these config files, networking would still be broken.

A headless kicksecure possible and this mac randomization won't break it,

Headless possibly but not on server. The server broke because the server provider does not allow MAC address changes. Each rented server must keep its assigned default MAC address as per server provider policy.

[monsieuremre]

Kicksecure is supposed to run on servers too

I do not support this idea. There is a reason why almost every distro has two distinct iso images for workstation and desktop. And no, it is not just the DE. It is a bad security practice to have a universal operating system. At the very least, there has to be two options, for server and for workstation. A lot of the desktop hardening measures will not apply to servers and in fact might break it. In the same way, a lot of server hardening won't be applicable to workstations. There are a lot of big things that we can't do on desktop, like hiding proc, that we can easily do on servers. Also on servers, it makes much more sense to just kill bluetooth in the kernel like previously. It also makes more sense on servers to kill a lot of things. There is a lot of place for extra hardening on servers. There are also stuff like this, which is not applicable on servers.

In my opinion, kicksecure should not thrive the be the universal operating system. Maybe it can have branches if desired. But firstly, I think the focus should be workstations. Because as you see, a lot of stuff won't be applicable to servers and workstations the same way.

[adrelanos]

Kicksecure is supposed to run on servers too

I do not support this idea. There is a reason why almost every distro has two distinct iso images for workstation and desktop.

At the very least, there has to be two options, for server and for workstation.

There's already two build targets for derivative-maker:

• --flavor kicksecure-xfce --target iso (resulting ISO comes with Calamares)
• --flavor kicksecure-cli --target iso (Unfortunately, Calamares does not run in CLI mode. (Add to Calamares the ability to run in Command Line mode calamares/calamares#530) So installer is unresolved. Will be looked into at later point.)

All packages have suffixes such as -cli or -xfce where needed. -cli is supposed to be compatible with servers.

And no, it is not just the DE. It is a bad security practice to have a universal operating system.

Things just need to be correctly split into CLI and GUI packages where needed. Not sure about security-misc.

• security-misc-shared (Maybe just "security-misc". This is what we have now. Though imperfect as it ships configs for desktop applications.)
• security-misc-desktop
• security-misc-server

Maybe one day.

[adrelanos]

There is now a ticket for the package split:

• Split the security-misc into security-misc-shared, security-misc-desktop and security-misc-server #187

Because if suitable at all to implement this, MAC randomization and IPv6 privacy, this only fits yet to be created package security-misc-desktop.

That ticket is also a blocker to make progress here.

Since package security-misc-desktop would also be installed by default in Kicksecure for VirtualBox and MAC randomization breaking VirtualBox DHCP as mentioned in my original post, I am not sure this functionality is suitable to have by default in Kicksecure anyhow.

Also corporate desktop systems are desktop systems. And in this environments, MAC randomization can break connectivity as they use (however useful, but it's done) MAC filters. There are also LAN based ISPs which are also likely to break.

I've just now spelled out the privacy goals and non-goals for Kicksecure here:
https://www.kicksecure.com/wiki/Privacy

Since Kicksecure is primarily focused on security, not privacy (for anonymity, look into Whonix), this feature has a very low priority for Kicksecure. Since high risk of all sorts of network breakage in different environments, this seems unsuitable to be enabled by default.

Also related:
https://www.kicksecure.com/wiki/Stable_Version_User_Experience

---

There might be a stronger case why a Whonix-Host should randomize MAC addresses by default. Related Whonix documentation wiki page:
https://www.whonix.org/wiki/MAC_Address

But security-misc package is owned of Kicksecure, not Whonix. Also since Whonix-Host is still unavailable at time of writing, discussing this here is both off-topic and pre-mature. So even if Whonix was to implement this, it would not necessarily through this package security-misc but potentially a different package.

related Whonix forum discussions:
https://forums.whonix.org/search?q=mac%20address

[monsieuremre]

At the very very least, mac randomization should be enabled when scanning for wifi networks, MacOS does this by default. There are actual corporations that use Mac systems. iPadOS, iOS and WatchOS do mac address randomization all the time every time as the default. GrapheneOs does mac os randomization, being a security based OS. TailsOS does this too, which is like, the thing that is probably most compared to whonix. Whonix may not need to do this, because it is in VM, and makes no real wifi connections anyway, but kicksecure will have to do it.

That is to underly, we are not reinventing the wheel here. If mac address randomization virtualbox DHPC, it is not a mac randomization issue, 100%. I suspect it is about ram caching or something. Because it is only apparent after a manual reboot in the box.

I do not know what do you mean by dhcp, a desktop system does not do dhcp. This should be very very clear. This is something that concerns servers or routers and stuff. If you are doing dhcp stuff, you are already on the server version of the package, so that should be no problem. If you mean that making dhcp request to the server is broken, then you are right, this may be problematic. But still then, this suggests the problem is most definetely a virtualbox one, that relates to, i am guessing, not clearing the memory when doing a manual reboot.

Also corporate desktop systems are desktop systems.

I see the same problematic approach that debian has again, trying to be universal and inevitably becoming the 'jack of all trades master of none' in the process. Corporate desktop systems won't use mac address randomization, they won't use kicksecure for many other reasons anyway, and Kicksecure should not try to target this audience, because it is already unrealistic.

But even if you do, mac randomization should still be enabled by default. Users can turn it off easily maybe with an option or config file or boot parameter we can provide. But the default behavior should be randomizing. A tiny unsignificant obstacle should not prevent big leaps like this.

[adrelanos]

Tails doesn't just enable MAC randomization or any feature but has a holistic view. Tails has a stronger need for this feature, has documentation and a GUI tool (the first boot wizard) allowing users to easily tinker and disable this feature. Tails doesn't just change any config and then lets users down. This is as per Tails merge policy, "Documentation is not optional".

Whonix VMs don't need MAC randomization but for Whonix-Host there's a stronger argument than for Kicksecure.

related:

• https://www.whonix.org/wiki/MAC_Address
• https://forums.whonix.org/t/your-mac-address-randomization-attempts-are-futile/2719

At the very very least, mac randomization should be enabled when scanning for wifi networks, MacOS does this by default.

MAC randomization while scanning is more reasonable as it shouldn't break networking.

I do not know what do you mean by dhcp, a desktop system does not do dhcp. This should be very very clear. This is something that concerns servers or routers and stuff. If you are doing dhcp stuff, you are already on the server version of the package, so that should be no problem.

No, DHCP is very much a desktop thing. Most Linux distributions nowadays presumably use Network Manger, which comes with its own built-in DHCP client. But that doesn't matter. Any Linux desktop distribution, Android, iOS come with a DHCP client. The DHCP client gets an internal LAN IP from the router (where a DHCP server is running). If DHCP gets disabled in the router settings, most client devices will have broken networking unless the user sets up static IP configuration.

Kicksecure (or Debian) inside VirtualBox by default uses DHCP through Network Manger's built-in DHCP client. It requests an internal LAN IP from VirtualBox's virtual DHCP server. This was broken, with no solution in sight, hence reverted.

Also corporate desktop systems are desktop systems.

I see the same problematic approach that debian has again, trying to be universal and inevitably becoming the 'jack of all trades master of none' in the process.

It is what it is. Being universal, not breaking Debian's features more than reasonably necessary has been always the goal. This will get only explained more and made more obvious but this will not change. Long standing quote from https://www.kicksecure.com/wiki/About#Usability_by_Default

Kicksecure aims to maximize usability by default so it can be utilized as an everyday, multipurpose operating system by users of all skill levels.

We might have some ideological, project goal, differences of opinion here.

Kicksecure isn't just for my personal computer security hardening. It needs to work for the actual users of Kicksecure. Knowingly breaking networking inside VirtualBox is not an option. Kicksecure usability is supposed to be better than Debian or Ubuntu. Ideally, I would like to be on the same level as Elementary OS. But that would require inventing/porting more components. That wouldn't just mean not breaking things and good documentation. Maybe one day. But at least not much worse than Debian.

Ubuntu... Actually not sure nowadays. ubuntu.com doesn't seem very user focused at the moment for users looking to download and install a Linux distribution. So my comment is more about how Ubuntu was in the past.

On the other hand, you view might be more similar to Arch or Gentoo Linux. Not beginner friendly. Works for me. Good enough. Breaks for someone? Never mind. Up to them to figure it out somehow.

Elaborated on, expanded just now:
https://www.kicksecure.com/wiki/Stable_Version_User_Experience

Corporate desktop systems won't use mac address randomization, they won't use kicksecure for many other reasons anyway, and Kicksecure should not try to target this audience, because it is already unrealistic.

I am aware of a few corporate users with more interest than I can handle.

[monsieuremre]

Most Linux distributions nowadays presumably use Network Manger, which comes with its own built-in DHCP client.

I think my point stands, since you mention it is the client, so it is indeed about making requests to the server, which I said would be problematic if that's the case.

Kicksecure usability is supposed to be better than Debian or Ubuntu.

If you mean being beginner friendly, then beating Debian is not that hard to be honest. Ubuntu on the other hand, is the distro. Until kicksecure has a live cd, that has a gui installer, that runs like a no brainer and after that everything is more or less intuitive, it can't be ubunut level usable. Which I have to say, is probably doable, I guess.

On the other hand, you view might be more similar to Arch or Gentoo Linux. Not beginner friendly. Works for me. Good enough. Breaks for someone? Never mind. Up to them to figure it out somehow.

Well I would disagree there. My mindset is quite the opposite. That's why I was suggesting targeting desktops only. Not breaking a desktop whilst hardening is not that hard. Doing that and being also compatible with everything else is the hard part.

[adrelanos]

Most Linux distributions nowadays presumably use Network Manger, which comes with its own built-in DHCP client.

I think my point stands, since you mention it is the client, so it is indeed about making requests to the server, which I said would be problematic if that's the case.

DHCP clients on desktops are the default. There no alternative except static IP configuration, which is cumbersome.

Hence Kicksecure (or Debian + security-misc) inside VirtualBox uses DHCP, which is the most common setup, the default, and to be expected. That shouldn't break since it's a very common use case except you want to exclude VirtualBox or VMs generally.

Kicksecure usability is supposed to be better than Debian or Ubuntu.

If you mean being beginner friendly, then beating Debian is not that hard to be honest. Ubuntu on the other hand, is the distro. Until kicksecure has a live cd, that has a gui installer, that runs like a no brainer and after that everything is more or less intuitive, it can't be ubunut level usable. Which I have to say, is probably doable, I guess.

Right. Quite close.

[adrelanos]

But true. A DHCP client (examples: desktop host or VM) makes a DHCP request to a DHCP server (examples: router or virtualizer host software). However, that is very common, very normal, and no reasonable way to avoid it. No way around DHCP. Could argue attack surface is lower without DHCP and that's true but manual IP configuration is pretty difficult for users.

[monsieuremre]

No no you are right, but still this problem is on virtualbox and only after manual reboot. I am very positive this can be solved whilst still randomizing the mac address. I think it might be a cache thing, as I said.

[monsieuremre]

I had no issues sshing into a VPS with MAC Address randomization or for better words mac spoofing enabled on debian

He means when mac randomization is enabled on the server side, like on the server OS. Not like your case, where it is on the client side. On server side it will cause problems almost 100%. Not to mention that mac randomization or privacy extensions on serve no purpose at all on a server anyway. So @adrelanos is right here.

Shouldn't IPv6 be disabled since it can cause issues with VPN users tho?

That is not true with all VPN providers and those users already take care of it themselves, being VPN users. Mostly the VPN client does take care of it if necessary.