pppd: do not rely on have_route_to(0) during auth.

[jkroonza]

#543 for reference.

Closes: #543

[jkroonza]

Impact assessment is surprisingly hard. The case that changes is where have_route_to(0) previously returned false for non-privileged users and neither auth nor noauth was set.

In other words, if we did have a default route, we'd suddenly require the remote side to auth, but if we did not we'd default to noauth (without allow_any_ip, meaning we could have multiple pppd's but only certain IPs would be available to the remote side). This feels counter-intuitive to me.

The motivation was that non-privileged users could establish internet connection without needing the privileged noauth option I believe. This use-case should be extremely rare nowadays, so just assume that a default route is already available, and force auth for all non-privileged invocations, meaning a system administrator would need to create a noauth peer for non-privileged users - typically managed via network manager nowadays anyway.

[Neustradamus]

@paulusmack: What do you think about this @jkroonza PR?

[paulusmack]

If I recall correctly, the reasoning was that adding a route to an IPv4 address that you can't otherwise get to is pretty benign, so we could let unprivileged users do that. But letting them use an IPv4 address that we already have a route to could provide a way to spoof some trusted host, so to control that, we require the peer to authenticate itself, meaning that the sysadmin has to have set up a secrets file entry for them, and that entry can then dictate the IP address the peer can use. Now if there is a default route, there are no IPv4 addresses that we don't have a route to, so any unprivileged use of pppd requires authentication. (Not all of this reasoning really still makes sense today, but I think this was what I was thinking 20 - 30 years ago.)

This change would mean that any use by an unprivileged user requires the peer to authenticate, unless they are using a privileged option file in /etc/ppp/peers that includes the "noauth" option. I think that sounds reasonable.

Apparently Debian sets up pppd to be setuid-root and executable by group "dip", and they ship with "pon" and "poff" scripts to set-up/tear-down a PPP connection to an ISP. The "pon" script by default uses /etc/ppp/peers/provider, which has the "noauth" option in it. So that wouldn't be affected by this change.

[jkroonza]

"Now if there is a default route, there are no IPv4 addresses that we don't have a route to"

Well, the reasoning is probably solid, and along comes someone like me and invalidates that completely:

# ip ro ad unreachable x.y.z.0/22
vtysh -c "conf t" -c "router ospf" -c "redistribute connected ..." -c "redistribute kernel ..."

Rigged so that the unreachable gets redistributed, and x.y.z.0/22 is redistributed into ospf (redistribute kernel) and redistribute connected is so that non-ppp connections can be redistributed, and route-maps to filter the dynamic /32s for ppp, but not any static ranges so that statically assigned addresses on pppoe does get redistributed.

Now, to defend the original statement: This isn't a desktop system. And auth is explicitly set up for sure.

Are we okay with the "minimum change" here, or should we perhaps rethink this entirely?

debian is generally (in my opinion) a good example to look at.

I think this "neither auth nor noauth" makes kinda sense, so it's really noauth but the remote side can only use unreachable IPs, I think now, so if you have a default, LCP will establish now, but peer address negotiation will fail. So it will just take longer to fail I think. I'm not sure how to test this.

Since IPv6 negotiates LLv6 only in any case, that should be fine, and DHCPv6 server would need to be configured already to do routing - so I reckon this is fine.

What we may want to consider is impact on defaulroute and defaultroute6 options ... can non-privileged users specify those currently? What will happen if either default is already installed on the system?

So perhaps defaultroute should become privileged if a default route for IPv4 exist, and defaultroute6 if default route for IPv6 exist?