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: Thu, 23 Jun 2011 08:41:34 +0800 From: Herbert Xu <herbert@...dor.apana.org.au> To: David Miller <davem@...emloft.net> Cc: netdev@...r.kernel.org Subject: Re: unintended ipv4 broadcast policy change On Wed, Jun 22, 2011 at 04:39:35PM -0700, David Miller wrote: > > The context is that I'm looking into cleaning up up the mess we have > wrt. DHCP listening on packet sockets and (in some cases) seeing every > packet that hits the system. > > Anyways, back in 2007 this commit was made: > > commit 8030f54499925d073a88c09f30d5d844fb1b3190 > Author: Herbert Xu <herbert@...dor.apana.org.au> > Date: Thu Feb 22 01:53:47 2007 +0900 > > [IPV4] devinet: Register inetdev earlier. It appears that the intention was to allow sysctl control prior to device open. > So now every net device registered has inetdev_init() called on it. > > This has a subtle policy side effect that has some interesting > implications. The route input slow path has this check: > > /* IP on this device is disabled. */ > > if (!in_dev) > goto out; > > But now this will never, ever, be true. If we ever wanted to disable IPv4 we could always add a sysctl for that, just like IPv6. > Which means that previously we would not accept even broadcast > or multicast packets on an interface that hasn't had at least > one IP address configured. > > Now we will. This indeed is an unintended side-effect. > I think we have a hard decision to make. One option is to > fix the input routing check, by changing it to test if the > ipv4 address list is empty. > > The second option is to remove the check entirely and keep the > new behavior. We could also add a disable_ipv4 sysctl and then replace this check in the routing code with a disable_ipv4 check at the very top of the IPv4 receive path, just like IPv6. > This subtle new behavior is interesting because it means that > a DHCP client could be implemented entirely with plain UDP > sockets. Yes this is indeed possible. However, for compatibility purposes I'm not sure whether we can safely rely on this new behaviour. Maybe if we add the disable_ipv4 sysctl we can use it to signal the presence of this new behaviour. Cheers, -- Email: Herbert Xu <herbert@...dor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- 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