nixos/wpa_supplicant: harden and run as unprivileged user

[rnhmjoj]

One more step towards zero services running as root.
Inspired by #305722

Things done

• Built on platform:
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• Tested
  • nixosTests.wpa_supplicant
  • nixosTests.networking.networkmanager
  • nixosTests.connman
  • wpa_supplicant, wpa_cli on my machine
  • connman on actual hardware
  • networkmanager on actual hardware
• Ran nixpkgs-review on this PR. See nixpkgs-review usage.
• Tested basic functionality of all binary files, usually in ./result/bin/.
• Nixpkgs Release Notes
  • Package update: when the change is major or breaking.
• NixOS Release Notes
  • Module addition: when adding a new NixOS module.
  • Module update: when the change is significant.
• Fits CONTRIBUTING.md, pkgs/README.md, maintainers/README.md and other READMEs.

---

Add a 👍 reaction to pull requests you find important.

[rnhmjoj]

Could someone from @NixOS/freedesktop help with testing this doesn't break NetworkManager?

[rnhmjoj]

@LeSuisse, since you're the only one to have touched connman recently, can you help testing?

[SuperSandro2000]

Shouldn't this be done via tmpfiles instead?

[rnhmjoj]

I always see tmpfiles being recommended, but it's not a substitute for a privileged prestart script. Even if I add an After=systemd-tmpfiles-setup.service, it's not guaranteed that the files actually exist when the service is started, they may have been deleted in the meantime.

[SuperSandro2000]

Why is that not guaranteed? What should delete those files? If the user deletes them then that is their fault.

[rnhmjoj]

What should delete those files?

I don't know, but why would I increase the chance of failure when I can just set up everything needed right before starting the service?

[illdefined]

Would it make sense to instead to rely on systemd.services.wpa_supplicant.confinement?

I remember that it was controversial when I wrote the Akkoma NixOS package.

[rnhmjoj]

I'm not familiar with this option: what's the difference?

[illdefined]

It creates a bind mount with only the store paths required to run the service.

[rnhmjoj]

store paths as in /nix/store paths?

[SuperSandro2000]

My last touch with confinement was in postfix-tlspol where it was removed again because it is not easy to debug.

[illdefined]

store paths as in /nix/store paths?

Exactly. It does so by producing a systemd override configuration from the closure information with BindReadOnlyPath directives for all required store paths: https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/security/systemd-confinement.nix#L218

I hacked together a similar thing for a systemd user service via Home Manager: ausweisapp.nix.txt

Instead of relying on RootDirectory like your proposal or the confinement module, it sets up an empty tmpfs with TemporaryFileSystem = "/:ro,nodev,noexec,nosuid", which I felt was cleaner.

[rnhmjoj]

It seems a bit extreme. What's the benefit of locking down /nix/store? The only thing I can think of is preventing wpa_supplicant from stealing some world-readable "secret" that went into the store.

[illdefined]

It seems a bit extreme. What's the benefit of locking down /nix/store? The only thing I can think of is preventing wpa_supplicant from stealing some world-readable "secret" that went into the store.

I believe the idea is not to hide confidential information but to reduce the set of executable code to the bare minimum required to operate the service.

Compared to other hardening features it may have a less favourable cost/benefit ratio, especially if run-time dependencies vary with configuration.

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/prs-ready-for-review/3032/5708

[rnhmjoj]

Since apparently no one is using nor maintaining them:

• NetworkManager:
  

• ConnMan:
  

For testing I modified the nixosTests.wpa_supplicant.mixedUsingSae with this patch:

Details

diff --git a/nixos/modules/virtualisation/qemu-vm.nix b/nixos/modules/virtualisation/qemu-vm.nix
index 0b0b2136ea03..77b63b23b8de 100644
--- a/nixos/modules/virtualisation/qemu-vm.nix
+++ b/nixos/modules/virtualisation/qemu-vm.nix
@@ -1435,10 +1435,6 @@ in
       VertRefresh 50-160
     '';
 
-    # Wireless won't work in the VM.
-    networking.wireless.enable = mkVMOverride false;
-    services.connman.enable = mkVMOverride false;
-
     # Speed up booting by not waiting for ARP.
     networking.dhcpcd.extraConfig = "noarp";
 
diff --git a/nixos/tests/wpa_supplicant.nix b/nixos/tests/wpa_supplicant.nix
index 2dbd5b5d18f5..d1bf62da480b 100644
--- a/nixos/tests/wpa_supplicant.nix
+++ b/nixos/tests/wpa_supplicant.nix
@@ -11,7 +11,7 @@ let
     ];
   };
 
-  naughtyPassphrase = ''!,./;'[]\-=<>?:"{}|_+@$%^&*()`~ # ceci n'est pas un commentaire'';
+  naughtyPassphrase = "reproducibility";
 
   runConnectionTest =
     name: extraConfig:
@@ -76,18 +76,100 @@ let
         };
 
         # wireless client
-        networking.wireless = lib.mkMerge [
-          {
-            # the override is needed because the wifi is
-            # disabled with mkVMOverride in qemu-vm.nix.
-            enable = lib.mkOverride 0 true;
-            userControlled = true;
-            interfaces = [ "wlan1" ];
-            fallbackToWPA2 = lib.mkDefault true;
-            secretsFile = "/var/lib/secrets/wpa";
-          }
-          extraConfig
+        networking = {
+          useDHCP = false;
+          useNetworkd = false;
+          firewall.allowedUDPPorts = [ 547 ];
+          interfaces = lib.mkOverride 0 {
+            wlan0.ipv4.addresses = [
+              {
+                address = "192.168.0.1";
+                prefixLength = 24;
+              }
+            ];
+            wlan0-1.ipv4.addresses = [
+              {
+                address = "192.168.1.1";
+                prefixLength = 24;
+              }
+            ];
+            wlan0-2.ipv4.addresses = [
+              {
+                address = "192.168.2.1";
+                prefixLength = 24;
+              }
+            ];
+          };
+        };
+
+        services.kea.dhcp4.enable = true;
+        services.kea.dhcp4.settings = {
+          interfaces-config = {
+            interfaces = [
+              "wlan0"
+              "wlan0-1"
+              "wlan0-2"
+            ];
+            dhcp-socket-type = "raw";
+            service-sockets-require-all = true;
+            service-sockets-max-retries = 5;
+            service-sockets-retry-wait-time = 2500;
+          };
+          subnet4 =
+            map
+              (n: {
+                id = n + 1;
+                subnet = "192.168.${toString n}.0/24";
+                pools = [ { pool = "192.168.${toString n}.3 - 192.168.${toString n}.254"; } ];
+                option-data = [
+                  {
+                    data = "192.168.${toString n}.1";
+                    name = "routers";
+                  }
+                  {
+                    data = "192.168.${toString n}.1";
+                    name = "domain-name-servers";
+                  }
+                ];
+              })
+              [
+                0
+                1
+                2
+              ];
+        };
+
+        services.connman.enable = true;
+        services.connman.networkInterfaceBlacklist = [ "wlan0-1" "wlan0-2" "wlan0" ];
+        environment.systemPackages = [ pkgs.connman-gtk ];
+
+        networking.networkmanager.enable = true;
+        networking.networkmanager.unmanaged = [ "wlan0-1" "wlan0-2" "wlan0" ];
+
+        services.xserver.enable = true;
+        services.xserver.desktopManager.plasma6.enable = true;
+        services.xserver.displayManager.autoLogin.enable = true;
+        services.xserver.displayManager.autoLogin.user = "vm";
+
+        virtualisation.memorySize = 2048;
+        services.spice-vdagentd.enable = true;
+        virtualisation.qemu.options = [
+          "-vga qxl"
+          "-spice port=5924,disable-ticketing=on"
+          "-device virtio-serial -chardev spicevmc,id=vdagent,debug=0,name=vdagent"
+          "-device virtserialport,chardev=vdagent,name=com.redhat.spice.0"
         ];
+
+        users.users.vm = {
+          password = "vm";
+          isNormalUser = true;
+          extraGroups = [
+            "networkmanager"
+            "wheel"
+          ];
+        };
+        security.sudo.enable = true;
+
       };
 
       testScript = ''

It's a bit tricky to run an 802.11 simulator, access point, DHCP server and wireless client all in the same host, but it worked.

[rnhmjoj]

By the way, these formatting changes are becoming annoying: they turned an almost theoretical problem (arguing about code style) into a very real one (constant merge conflicts).

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/prs-ready-for-review/3032/5787

[tazjin]

Duplicating my message from Matrix:

I think that this needs to be reverted. I believe it hasn't made it into a stable release yet. The breakage it causes for non-trivial use-cases is extensive and hard to recover from. This kind of massive change to a core component of the system (wifi!) should be feature-flagged, and not just rolled out like that without a way to turn it off.

If this makes it into a stable release as-is it is very likely that some people with enterprise networking setups (even something as simple as eduroam) end up offline after upgrading, until they roll back. For more complicated setups (such as TPM-based authentication) I haven't even been able to get this to work yet, as it requires complicated configuration of a plethora of additional accesses (to devices, mutable files, dynamic libraries and so on).

Of course the general idea is laudable, but something this core needs to be done more carefully.

[phaer]

Agreed, @rnhmjoj could you revert or offer an option for opt-out? While it seems to work well enough for common use cases that it took weeks for many to notice - thank you for testing properly! - opting-out should still be made easy for a while IMO.

And unless I am mistaken, there wasn't any effort to discuss the patch to wpa_supplicant with upstream before merging?

(I also think merging such a big change yourself, seemingly without any approvals is less than ideal to be honest)

[rnhmjoj]

I'm working on adding an option to disable the hardening sandbox, but still keeping wpa_supplicant running as its own user. I think this will allow you to keep your setup as is, without having to remove the wpa_supplicant patches.

[rnhmjoj]

Please take a look at PR #484382, can you tell me if that solves your problem?

[SuperSandro2000]

I think this is a good change on making the default NixOS desktop installation more secure and systemd-analyze security more happy. Such changes will never go without breaking something, especially if we retrofit it into such a core component, but having an option to opt-out of it is a good option to fix peoples setup until we can better handle their usecases.
Ideally we could detect usages of eduroam or tpm and then relax the sandbox or we add options where those are allowed per default and people can lock it more down.

Maybe it is also worth to take another look at the release notes and expand them with those specific usecases to put more attention to them.

[rnhmjoj]

Ideally we could detect usages of eduroam or tpm and then relax the sandbox or we add options where those are allowed per default and people can lock it more down.

I think most of the users who reported a problem didn't have a declarative configuration, in which case an option to manually disable the hardening is still required. Otherwise, it could probably be done if someone provides some examples.

Maybe it is also worth to take another look at the release notes and expand them

Yeah, I'm also working on improving the manual, which was very outdated and incomplete. See #483534

[phaer]

@rnhmjoj Sorry, could you please respond to my request of at least adding a feature-flag around this?

Doing so has been a thing for significant changes to core parts of NixOS for quite a while now and included unanimously welcomed changes (such as systemd-in-initrd & nixos-rebuild-ng for example) and has no discernible drawbacks IMO.

As it stands:

• This requires manual intervention for many, if not most, users of eduroam
• This breaks at least some uses of enterprise WiFi setup.
• There's no mention of this change or required adaptions in user setup (i.e. cert location & perms) in the release notes.

You seem to deliberately want to break user setups in order to force feedback:

I really did my best to test it as thoroughly as possible, but some setup are simply inaccessible to me. I know it's not fair, but sadly the only way to get some feedback for NixOS changes, as of lately, is to cause a breakage.

I do think this stance is unacceptable for a committer and kindly ask you to reconsider.
It's absolutely normal that you can't get a total view of all possible WiFi setups. And your goal to harden wpa_supplicant is laudable, but this kind of brute-force attempt is not okay IMO.

[rnhmjoj]

See #484382

[phaer]

This is a feature-flag for one part of the PR, but judging by the diff it does not affect the permission changes around certificates (the eduroam issue).

Nor does it update the release notes.

[rnhmjoj]

This is a feature-flag for one part of the PR, but judging by the diff it does not affect the permission changes

This requires #480355 (comment) many, if not most, users of eduroam

Yes, I understood that and I mentioned it in the release notes. It's not something unheard of... you may need to perform some manual step when updating between NixOS stable versions, or if you're on the unstable NixOS channel.

This breaks at least some uses of enterprise WiFi setup.

#484382 addresses this. Breaking the enterprise networks setup is of course unacceptable and that's why I'm adding an option to revert the hardening; but I don't think that mandating proper ownerships of some files is that unreasonable. Still, I could throw in a CAP_DAC_OVERRIDE and it would also revert that, if you insist.

There's no mention of this change or required adaptions in user setup (i.e. cert location & perms) in the release notes.

This is not true, see https://github.com/NixOS/nixpkgs/blob/master/nixos/doc/manual/release-notes/rl-2605.section.md?plain=1#L103. I will nontheless improve the documentations and instructions (see #483534) once enableHardening is merged.

[tazjin]

#484382 addresses this.

It doesn't, though. Even with all those changes applied as overrides, having reverted the wpa_supplicant patch, forcing the service to run as root again, adding / to the bind mounts and so on I'm still getting mysterious permission errors. There's still a huge number of complex systemd options in the service that wasn't there before, and I have to debug these one-by-one.

The toggle needs to completely undo the original changes.

[SuperSandro2000]

Couldn't initialize supplicant interface: GDBus.Error:fi.w1.wpa_supplicant1.UnknownError: wpa_supplicant couldn't grab this interface.

From what google shows me, that could be a red herring and was already an issue before.

https://forum.manjaro.org/t/troubles-with-networkmanager/38420/5
https://askubuntu.com/questions/1542014/wifi-doesnt-find-networks-after-sleep-mode-ubuntu-24-04-msi-laptop
#222181

This should be fixed with the sleep fix already done. If you're current issue is different, please share that.

The toggle needs to completely undo the original changes.

What you are asking for, is running a service that talks to potentially untrusted input with complete root permissions, so every exploit would be fatal. I understand that migrating of that can be painful but we need to start somewhere and try to move in the right direction and for that we need feedback. I think having an option which opens things up for the next release(s) is great but we then also need to receive actionable feedback where we can improve things and make the secure default work properly.

but I don't think that mandating proper ownerships of some files is that unreasonable. Still, I could throw in a CAP_DAC_OVERRIDE and it would also revert that, if you insist.

No, it isn't. I think the best example is ssh: when there permissions are to wide, it just refuses to use the files.

[tazjin]

From what google shows me, that could be a red herring and was already an issue before.

Sorry, you're way behind on the discussion of that particular error. Read the related threads.

What you are asking for, is running a service that talks to potentially untrusted input with complete root permissions, so every exploit would be fatal

What I am asking for is the status quo. As has been said before, it's great that you want to move in a more secure direction (although of course I am wary of all the bugs in systemd in this regard), but you can't do this by breaking workflows completely and without providing a way to fix it. Right now, this requires strace'ing wpa_supplicant and carefully debugging what exactly it's running into to try and work around all the problems, which is absolutely non-trivial and which the vast majority of users probably won't be able to do.

[phaer]

This is not true, see https://github.com/NixOS/nixpkgs/blob/master/nixos/doc/manual/release-notes/rl-2605.section.md?plain=1#L103. I will nontheless improve the documentations and instructions (see #483534) once enableHardening is merged.

My apologies, I stand corrected regarding the release notes. Not sure how I missed this in my original reading.

Still, the rest of the argument still stands: it should be possible to opt these changes completely. Deliberately breaking User setups to force feedback is not okay

[iclanzan]

This PR breaks using the iwd NetworkManager backend in conjunction with networking.wireless.networks. I’ve been using this combination fine for the longest time. Now evaluation fails with:

       - You can not use networking.networkmanager with networking.wireless.networks.
       Except if you mark some interfaces as <literal>unmanaged</literal> by NetworkManager.

[rnhmjoj]

This PR breaks using the iwd NetworkManager backend in conjunction with networking.wireless.networks

Similarly to #479042 (comment), please don't do this: it worked mostly by accident and has never been tested. When using NetworkManager you should configure networks declaratively with networking.networkmanager.ensureProfiles.

[phaer]

What you are asking for, is running a service that talks to potentially untrusted input with complete root permissions, so every exploit would be fatal.

As we did for ages and upstream still recommends, as illustrated by the fact that we need an in-tree patch to even support running unprivileged. A patch that afaik hasn't even been proposed to upstream.

I understand that migrating of that can be painful but we need to start somewhere and try to move in the right direction and for that we need feedback

Yes, and that "somewhere" is a feature-flag, not a forced breakage of user setup.s

[rnhmjoj]

Reminder that #484382 is still waiting for your feedback.

[rnhmjoj]

The option networking.wireless.enableHardening has been merged (#484382) and the manual and release notes updated to include it (#483534).

[boomshroom]

I have NetworkManager handling ethernet, and don't have wireless networks configured since I don't use any, but I also have the read-only etc overlay enabled, which breaks the new service definition attempting to create /etc/wpa_supplicant/imperative.conf. This in turn breaks nixos-rebuild switch entirely.

[rnhmjoj]

I have NetworkManager handling ethernet, and don't have wireless networks

I guess you can safely disable wpa_supplicant, then. Use networking.wireless.enable = lib.mkForce false.

have the read-only etc overlay enabled

Don't do this? Many services expect /etc to be writable, including NetworkManager, wpa_supplicant, resolvconf, etc.

/etc/wpa_supplicant/imperative.conf

This is actually not needed if wpa_supplicant is controlled from dbus. The condition could probably be refined to deal with this case.