Allow temporary changes to make CaptivePortal logins work

[secretmango]

Component

systemd-resolved

Is your feature request related to a problem? Please describe

When using a sane systemd-resolved configuration with DoT, DNSSec a custom DNS server, Captive portals simply dont work.

When using Firefox to log into them, you can't use just the DHCP advertised DNS server in Firefox afaik, as the "insecure fallback" would be to use system DNS.

Describe the solution you'd like

So there needs to be a way to temporarily disable the security settings, that GUI desktops etc can integrate, for allowing the login for that captive portal and then securing the setup again.

Best would be to launch a specific process with these weak settings, and when it is closed revert back to normal. Idk if possible, but having seperate DNS configs just for Captive Portals and the like would also be really great for privacy and security.

Describe alternatives you've considered

having a hacky workaroung like this, switching between two override configs and reloading the daemon. This is very time intensive and not efficient.

Maybe manually disabling certain parameters using resolvectl, but either the user settings would need to be hardcoded or you would need to reload the daemon to reset back to the secure configs afaik

The systemd version you checked that didn't have the feature you are asking for

253

[rpigott]

Active probes for legacy captive portals do not work with dnssec. Going forward clients will need to learn about captive portal uri from the network configuration [1][2] — networkd supports this passive detection:

$ networkctl status enp7s0
[...]
Required For Online: yes
     Captive Portal: urn:ietf:params:capport:unrestricted           
    DHCP4 Client ID: IAID:0x7b31fe60/DUID
  DHCP6 Client DUID: DUID-EN/Vendor:0000ab1176675fdb85f2cfdb0000

The uri is hyperlinked in most terminals for you to visit.

[1] https://developer.apple.com/news/?id=q78sq5rv [2] https://developer.android.com/about/versions/11/features/captive-portal

[poettering]

Active probes for legacy captive portals do not work with dnssec. Going forward clients will need to learn about captive portal uri from the network configuration [1][2] — networkd supports this passive detection:

that's only going to work for really new environments though. for legacy networks we must find a way.

So i am sympathetic to this, but i think the problem is bigger than just adding such a "temporary downgrade".

for security reasons it should only be the captive portal UI thing that gets access to the network and unauthenticated dns. Something like that probably needs to be implemented via vrf.

i.e. we probably should have a mechanism that a network management UI can run a mini webbrowser inside a VRF sandbox if you so will that gets access to the host network even though regular apps don't just yet. And then we'd have to teach resolved somehow to honour this too. which probably means two things:

1. for dbus/varlink requests resolved should read some xattr off the client's cgroup that systemd sets that controls whether the app shall get access to dns at all, only with strong auth or totally relaxed. (other knobs should be whether llmnr/mdns is allowed, and so on)

2. for stub requests we should probably listen on a new ip address 127.0.0.55 which would be just like 127.0.0.53 but with the relaxed crypto policy applied. the VRF sandbox for that mini browser would then be told to talk to that stub (and the others are blocked or so)

net result: no dnssec and suchlike for the mini browser. full protection for the rest of the apps

i think android implements their captive portal stuff with VRF too. but it might be worth figuring out what they precsiely do (and if my VRF assumption is actually true at all)

[rpigott]

If the network manager is making active probes for captive portals, it is blocked by dnssec, and it talks to the stub, can't it just use the cd bit to get around that? Seems easier than adopting a new bus api and us implementing a new listener.