dhcpcd icon indicating copy to clipboard operation
dhcpcd copied to clipboard

global IPv6 addresses leaked into the journal (when invoked by networkmanager)

Open luebking opened this issue 2 years ago • 6 comments
trafficstars

I think it's b/c NM puts dhcpcd into debug mode - maybe global addresses can generally be ellipsed or only shown when dhcpcd logs to a tty?

https://bbs.archlinux.org/viewtopic.php?id=289820

luebking avatar Oct 25 '23 07:10 luebking

I think this is more of dhcpcd logging to syslog(3). The arch systemd service script disables syslog, but the NM plugin does not.

I guess some options would be to provide a nosyslog option and maybe a configure --without-syslog option as well.

Thoughts?

rsmarples avatar Oct 27 '23 12:10 rsmarples

The dhcpcd service in general frequently show up in logs (but maybe just the "warnings" for carrier changes) NM possibly could use -q as well, but tends to be very chatty in everything it does (eg. w/ its wpa_supplicant invocation)

Do you think this kind of data needs to be fully logged anywhere when not debugging?

I'd probably just obfuscate the central bytes 1234:xxx:xx:xxx:xx:xx:xx:56/64 - you know you got a global IP and can correlate other data w/ the last byte and on the rare occasion that the actual IP is relevant for inspection, one will have to run dhcpcd in debug mode.

luebking avatar Oct 27 '23 14:10 luebking

Do you think this kind of data needs to be fully logged anywhere when not debugging?

My immediate reaction was yes absolutely. All other DHCP clients log IP addresses and they run on CPE devices with public IPv4 addresses. However not many DHCPv6 clients in comparison and potentially addresses could be more public than IPv4.

But I've thought about it some more and I cannot refute your argument and really, does anyone care about addresses? It's supposed to be plug and play.

I'll take some time to ensure addresses are ONLY logged when debug is enabled.

rsmarples avatar Nov 07 '23 09:11 rsmarples

Please don't implement this, or at least go with your original idea of relying on a non-default config option. IP address obfuscation is security theater at best. If one insists on not revealing "secret" information like IP addresses in a log file, then they should rely on other tools like read permissions on the file, syslog.conf(5), or whatever other tools the OS provides—I would strongly suggest to rethink the idea as a whole and actually think how difficult it would be for someone to obtain this information by other means to realize how meaningless this is. Keeping this information does not violate the "plug and play" ideology either.

Why should one have to run dhcpcd in "debug" mode to see this information? Running code in "debug" mode is an actual, albeit temporary, reduction in security since more code gets executed which means more bugs that can potentially be exploited.

As you said, @rsmarples, DHCP daemons log IPv4 addresses; and I am pretty sure ISC's Kea DHCP daemon (which has DHCPv6 abilities as well) logs IPv6 addresses as it should.

zacknewman avatar Nov 14 '23 15:11 zacknewman

Not "secret", "private" - the concerned condition was that the journal is frequently (semi-)publically shared for problem analysis, so local read permissions won't cut it.

Obtain what information? Your present publically routable or otherwise IPv6 (and IPv4)? ip a

Or the complete publically routable IP you got 5 days ago? Do you intend to surveil a system (that's not meant as a criticism, there're benign reasons for that) with the system-local logs (that, however, is rather silly)?

IPv4 is typically LAN (for non-router systems) and therefore unaffected by these concerns.

I basically don't really care how this leaves the logs - whether generally or w/ a more fine-grained "-q" that's usd by the NM plugin or the NM plugin just replicating the service and going fully "-q". But the thread starter in the BBS has a point: we cannot ask users to unwittingly expose themselves. And from some little experience, the users that are required to share their journal to find their problem for them are not capable of filtering sensitive data themselves. It cannot show up there (and usually doesn't, eg. NM obfuscates keys etc.)

luebking avatar Nov 14 '23 21:11 luebking

Maybe I misunderstood this request. If the change only affects NetworkManager, then whatever. I don't want dhcpcd to not log this information universally though as I don't hold the same opinion that IP addresses are "private" and revealing them "exposes" someone and personally find benefit in having this information logged via syslogd(8).

I don't know how common NetworkManager is in "router" situations, but I think it's important to not specialize dhcpcd for non-router situations unless dhcpcd explicitly markets itself as primarily a DHCP and DHPCv6 client for non-routers which it currently does not.

zacknewman avatar Nov 14 '23 23:11 zacknewman