lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Sun, 24 Jun 2007 22:17:31 -0400 From: Dan Williams <dcbw@...hat.com> To: "C. Scott Ananian" <cscott@...top.org> Cc: Rémi Denis-Courmont <rdenis@...phalempin.com>, David Stevens <dlstevens@...ibm.com>, netdev@...r.kernel.org Subject: Re: [RFD] First draft of RDNSS-in-RA support for IPv6 DNS autoconfiguration On Sat, 2007-06-23 at 10:47 -0400, C. Scott Ananian wrote: > Rémi and Simon give my responses very eloquently. Although you could > have yet-another-network-daemon redundantly process RA messages, the > kernel is doing it already and it makes sense to just push this > information to userland using /proc and/or netlink. Although parsing > RA messages and processing expiry in userland looks barely-possible > now, SeND support is really necessary for long-term IPv6 security, and > duplicating SeND functionality in userland would be a nightmare. > Futher, the neighbor discover protocol involves Router Solicitation > messages which elicit the Router Advertisement reply, and we really > don't want userland sending redundant Router Solicitation messages > around, just because the kernel doesn't want to tell it what Router > Advertisements it received. I considered storing the *complete* > Router Advertisement messages received and pushing them unparsed to > userland, just to get around the bogus "DNS in the kernel" politics > (hint: it's not a resolver in the kernel, it's just nameserver > addresses being stored). Does anyone really suggest that this would > be a better solution? > > The goal is to push the userland component into glibc, likely through > a NSS resolver plugin. Current glibc doesn't do any processing to > determine when /etc/resolv.conf has changed, which is a problem for The glibc guys rejected things like periodically stat()-ing resolv.conf. The standard solution to this has been to push the responsibility for noticing resolv.conf changes to _each_ _app_, which must periodically call _res_init() to get glibc to re-read resolv.conf and notice any changes. This is what eg Mozilla/Firefox and other internet-type apps do right now. Or, run a caching nameserver and point resolv.conf to 127.0.0.1, or use nss_lwres, which hopefully is in much better shape than it was a year or two ago (ie, actually respecting TTL and such). Dan > long-running applications. Exporting RDNSS-in-RA via netlink messages > (or by poll() on a /proc file as is done for /proc/<pid>/mounts, which > was suggested in linux-kernel) is an elegant solution that (as Rémi > noted) cleanly handles interface up/down/reconfig, route expiration, > and (eventually) the cryptographic neighbor discovery protocol without > weaving a web of hairs from the kernel to the resolver. > --scott > - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists