Repository navigation
MAC randomization breaks root server and VirtualBox DHCP / IPv6PrivacyExtensions might be problematic #184
Description
Activity
- added a commit that references this issue
on Jan 6, 2024 Therefore disabled just now in git.
- changed the title
[-]MAC randomization breaks VirtualBox DHCP[/-][+]MAC randomization breaks root server and VirtualBox DHCP[/+]on Jan 7, 2024 - changed the title
[-]MAC randomization breaks root server and VirtualBox DHCP[/-][+]MAC randomization breaks root server and VirtualBox DHCP / IPv6PrivacyExtensions might be problematic[/+]on Jan 7, 2024 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.
- added 2 commits that reference this issue
on Jan 7, 2024 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=79198Curious 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.
By server I mean server.
kicksecure.comitself 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.
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. (https://github.com/calamares/calamares/issues/530) So installer is unresolved. Will be looked into at later point.)
All packages have suffixes such as
-clior-xfcewhere needed.-cliis 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.
There is now a ticket for the package split:
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-desktopwould 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/PrivacySince 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_AddressBut 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%20addressTails 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.comdoesn'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_ExperienceCorporate 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.
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.
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.
Looking at this, I appreciate the sentiment, but don't think that the suggested implementation in the bounty is the correct one. We try to implement as many of our features as possible in packages rather than in installer scripts, so that we have a fairly consistent feature set and user interface across all supported hypervisors and physical machines. Implementing this in Calamares would be possible (and wouldn't even be that challenging, from having written Calamares modules it's probably a three-hour job to get the module itself written), but then only physical machines would get the feature, not virtual machines. Implementing this in upstream Calamares would also be a bit weird since many Linux operating systems probably won't want this.
Now that we have security-misc-desktop and security-misc-server split, maybe we can implement this as a default feature in one of those packages. Alternatively, maybe we could make a configuration utility? Would require some more thought and research, but in any event, I think Calamares is the wrong place to implement this.
Reacted by Patrick Schleizer
https://github.com/Kicksecure/security-misc/blob/master/usr/lib/NetworkManager/conf.d/80_randomize-mac.conf
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.