On Fri, Jun 12, 2015 at 10:33 AM, Dan Williams <dcbw@xxxxxxxxxx> wrote: > On Thu, 2015-06-11 at 14:41 -0700, Andrew Lutomirski wrote: >> On Thu, Jun 11, 2015 at 1:48 PM, Dan Williams <dcbw@xxxxxxxxxx> wrote: >> > On Tue, 2015-06-09 at 12:30 -0400, Matthew Miller wrote: >> >> On Tue, Jun 09, 2015 at 11:34:39AM -0400, Paul Wouters wrote: >> >> > decision needs to then be made by the system. I believe that's been >> >> > mostly due to lack of time for the various parties to sit down and >> >> > plan and then program this further. >> >> >> >> We should try to make that happen. >> > >> > Unfortunately the Proposal doesn't say anything about how this will >> > actually work, which is something NetworkManager needs to know. It also >> > fails to address the failure cases where your local DNS doesn't support >> > DNSSEC or is otherwise broken here out of no fault of your own. >> > >> >> > >I see that there's a "hotspot sign on" option if you right click on the >> >> > >icon. How does this work with Network Manager and GNOME's captive >> >> > >portal detection? >> >> > I have never seen those work except for when the backend was down and >> >> > I got a stream of false positives. But possibly that is because I've used >> >> > dnssec-trigger for years now and it might win the captive portal >> >> > detection race. There are some bugs once in a while but overal it works >> >> > pretty reliably. >> >> >> >> I think that's probably it — the race. The hotspot signon thing works >> >> for me at coffeeshops. Or it did before I enabled this feature. We'll >> >> see now! >> > >> > So, if you're behind a portal then unbound could potentially fail all >> > DNS lookups. That means that NetworkManager's connectivity detection, >> > which relies on retrieving a URL from a known website, will fail because >> > the DNS lookup for it was blocked by unbound. Thus GNOME Shell portal >> > detection will also fail. That kinda sucks. >> >> I think that part of the problem is that there are too many >> implementations of captive portal detection and too many >> half-thought-out implementations of what do do if a captive portal is >> detected. >> >> I think that, on a well-functioning system, if I connect to a wireless >> network, something should detect if I'm behind a captive portal. If >> so, I should get a stateless browser that clearly indicates that it's >> a captive portal browser, probably lives in a sandbox, and sees the >> raw view of the network (no local DNSSEC validation). We have network >> namespaces -- the browser part is doable even in a scenario where we >> wouldn't want to expose the incorrect view of DNS or some other aspect >> of the network to normal applications. (Heck, on a configuration >> where we want to use a VPN over untrusted wireless, we could avoid >> exposing the untrusted wireless network to applications other than >> captive portal login at all.) >> >> Please note that the current GNOME captive portal mechanism is >> blatantly insecure, and I've already filed a bug report with no >> resolution. I'm not disclosing a subtle 0-day here -- the insecurity >> is fairly obvious. I'll probably post to oss-security soon, but >> that's a somewhat separate topic. >> >> Once we determine that there's no captive portal or that we've logged >> in to it, we should validate DNSSEC and otherwise behave sensibly. If >> the network is screwed up enough that normal DNSSEC can't get through >> the DHCP-provided resolver (which happens -- I've seen ISPs that >> tamper with DNS results for www.google.com), then we should tunnel >> around it. IIRC dnssec-triggerd already supports this. > > So it sounds like there are two levels here: > > 1) connectivity detection and hotspot login using the network-provided > DNS servers, which are quite possibly insecure and/or broken > > 2) once that is all done, handling DNSSEC issues if the network-provided > DNS servers are insecure/broken. > > Which is fine; I'm mostly concerned with #1 at this point because I > don't think NetworkManager has much to do with #2 since it already has > mechanisms to push the network's DNS servers to whatever wants it > (unbound, etc). Fair enough. To me, it seems like the awkward interaction is that we sort of have a layering violation. If we think that NM and hotspot login's job is to detect a captive portal and possibly enable a UI to log in and the DNS resolver's job is to never give insecure results, then we need some way to let the portal login UI function without interacting with the DNSSEC-validating DNS server. This might need either special glibc support or some kind of container that can override /etc/resolv.conf just for the purpose of captive portal login. If the ultimate solution ends up involving namespaces, I'd be more than happy to help. > > I think the *UI* for connectivity indication and portal login certainly > is a desktop specific task, because it's part of the network connection > user experience. Whether that's GNOME or KDE or LXDE or whatever > doesn't matter, but all those environments have preferred ways of > interacting with network connections and portal login will need to be > part of that. > > The backend that actually does the connectivity checking (to detect > portals or whatever) doesn't need to be part of the UI workflow, and > could certainly be provided by a small, simple service that does this on > request of things like NM or dnssec-trigger or GNOME Shell or KDE or > whatever. If that's the path forward, I have thought to contribute > there as well. All of this seems reasonable. I'm currently very unhappy with gnome-shell's UI for this, but that's not a legitimate reason for me to say that some other project should take over the UI part. > >> to be aware of connectivity changes, and it should probably integrate >> more deeply than that, but if the end solution bypasses NM's captive >> portal detection entirely, that doesn't seem like an a priori problem >> to me. > > I honestly don't care much where the checking happens, but NM has > connectivity indication as part of it's API and we have to keep that for > a while, whether or not the implementation changes. But there are other > considerations about what does the checking as it relates to NM, because > there are many consumers of it and not all of them will install unbound > or dnssec-trigger. > >> Merging all of dnssec-triggerd into NM might be a decent solution. > > Honestly I'd rather see a very small, single-purpose daemon (say, > 'connectivityd' or whatever that has one simple job, to do the checking > upon request of NM/UI/whatever. DNSSEC failures would get handled > separately; for example, could more of the failure-type logic be pushed > to unbound instead, since it's the resolver here? > >> Keep in mind that a good DNSSEC solution is fundamentally tied to >> captive portal login. There are probably many captive portals behind >> which it's impossible to get DNSSEC before login but where, once >> logged in, tunneled or even normal DNSSEC is possible. > > Right; to me this says that we simply don't tell the rest of the system > that we're connected until we've gone through portal login. But > whatever does connectivity checking and whatever UI does portal login > would have access to the network-provided DNS servers (untrusted of > course) to complete their jobs, and finally when it's indicated that > we're logged in do apps start using the network DNS servers. Or if > those are broken, tunneled servers or something. All that makes sense. Thanks. FWIW, I think that a little C program to spin up a namespace that's good enough to point a stateless Firefox instance at a captive portal login with overridden DNS nameserver settings would only be a couple of hundred lines of code. It could even accept a netns to use as part of its input. The only hard part would be convincing Firefox to show an appropriate UI. It wouldn't really have to be Firefox, but getting the browser chrome right to avoid trivial phishing attacks is critical, and all real browsers already do that fairly well, whereas the simple embedded web views (e.g. gnome-shell-portal-helper) get it nearly 100% wrong. --Andy -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
