GNOME Bugzilla – Bug 752534
make the portal helper use the connection-provided dns servers
Last modified: 2021-07-05 14:27:07 UTC
We can't rely on resolv.conf to have proper, working information before the portal login is complete. After discussing this with the dnssec-trigger team on the Fedora side, we should find a way to explictly make the portal helper use the dns servers that are specified in the connection configuration. Two possible approaches: 1) use an LD_PRELOAD hack like https://github.com/hadess/resolvconf-override 2) set up some minimal containerization around the portal helper and bind mount a suitable resolv.conf in place
A little bit of background: In Fedora, we plan to use Unbound as local DNS resolver together with dnssec-trigger as a tool for dynamic reconfiguration of Unbound. dnssec-trigger implements its own Captive Portal detection mechanism (fetching static HTTP site with known content), but it conflicted with NM functionality and GNOME portal helper. Therefore we decided the disable the Captive portal detection in dnssec-trigger and also not to use dnssec-trigger panel for user interaction. Unbound is a validating resolver and does DNSSEC validation by default. Spoofing DNS answers is considered an attack, therefore we can not configure it with the connection provided DNS resolvers before the Captive portal login happens. Thus querying 127.0.0.1 would not give the portal helper the correct answer. Since we don't do the Captive portal detection and nm-dispatcher is not capable of notifications on Connectivity State changes we also don't know when to replace the 127.0.0.1 in resolv.conf with connection provided resolvers. This boils down to the fact that when doing the Captive portal login, the portal helper can not really assume that the resolvers in resolv.conf are usable for name resolution (for the purpose of logging into portal). Therefore portal helper should fetch the DNS resolver IP addresses from NM via DBus API and query those directly. NM Connectivity State currently reflects only state of the default connection, but using the connection specific DNS resolvers for portal login will enable logging into portal for non-default connections. E.g. situation when you are connected to wired network and at the same time to Wireless with Captive portal.
Created attachment 310604 [details] [review] portal-helper: Use xdg-app to have a private view of the file system In some cases we need to use different DNS servers than configured system-wide in /etc/resolv.conf. To achieve this so that webkit uses this particular set of DNS servers in a transparent way is to make us run with a private view of the file system where we can control the contents of /etc/resolv.conf without touching the system instance of that file. xdg-app-helper allows us to create such an environment in an easy way without needing to be root while still sharing IPC, network and Shm namespaces with the current user session. If xdg-app-helper isn't in PATH at runtime, we transparently fall back to run just as we did before.
Created attachment 310605 [details] [review] portal-helper: Ensure we use the current NM connection's DNS servers On systems with a local DNS resolver doing DNSSEC validation we aren't able to resolve names using the system DNS configuration in /etc/resolv.conf since that just points to the local resolver which refuses any requests until the user logs in through the portal and our host gets a working route to the internet. If we are running in a sandbox where we can write to a private instance of /etc/resolv.conf, we can use the DNS servers provided by the network administrator and made available to us by NetworkManager, for own process only and thus be able to resolve names so that we can load the portal.
(In reply to Rui Matos from comment #3) Hi Rui. Thank you for all your work. Is there any estimate on when these changes will be included in the Gnome release? Thank you.
Review of attachment 310604 [details] [review]: xdg-app-helper doesn't exist anymore. This needs porting to bubblewrap.
Review of attachment 310605 [details] [review]: The approach looks correct, but I wonder whether we should also make sure that the traffic only ever goes through the interface which we're trying to configure, rather than "the default gateway".
(In reply to Bastien Nocera from comment #5) > Review of attachment 310604 [details] [review] [review]: > > xdg-app-helper doesn't exist anymore. This needs porting to bubblewrap. Which might also solve bug 769692, if we don't have access to GSettings to read the proxy settings (?).
(In reply to Bastien Nocera from comment #6) > Review of attachment 310605 [details] [review] [review]: > > The approach looks correct, but I wonder whether we should also make sure > that the traffic only ever goes through the interface which we're trying to > configure, rather than "the default gateway". Hello Bastien and thank you for reviewing this bug. As I mentioned at the bottom of comment #1, the usual situation will be that the captive portal is on the default connection (marked as such by NM) and therefore the connection will be used as the default route for network communication. Nevertheless things in NM might change since 2015 in a way that NM is able to report the captive portal also for non-default connections. In my opinion a more generic solution would be to make sure that when doing captive portal login, the communication goes through the interface that is being configured (and from which DNS resolvers are used by the portal helper).
Review of attachment 310604 [details] [review]: ::: src/gnome-shell-portal-helper.c @@ +66,3 @@ + return TRUE; + + return FALSE; This needs to report FALSE if on non-Linux or bwrap isn't available. @@ +80,3 @@ + app_helper_path, + "-f", "-g", "-i", "-n", "-s", + "-b", "/etc/pki=/etc/pki", /* webkit needs this */ "-f", // Mount the host filesystems read-only "-g", // Allow use of direct rendering graphics "-i", // Share IPC namespace with session "-n", // Share network namespace with session "-s", // Share Shm namespace with session "-b", "/etc/pki=/etc/pki", /* webkit needs this */ // Bind extra source path read-only into DEST "/usr" // run-time path I documented the arguments, to make it easier to port to bwrap. I'd also note that the helper is very specific. Maybe an additional flag could be passed so we can change the args if we were to use it for something else, or it needs a more specific name.
Hi. Is there any update or progress on this issue?
(In reply to Tomas Hozza from comment #10) > Hi. > > Is there any update or progress on this issue? It's waiting for someone to provide an updated patch.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/ Thank you for your understanding and your help.