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: Fri, 11 Jul 2008 15:27:58 -0400 From: Neil Horman <nhorman@...driver.com> To: David Stevens <dlstevens@...ibm.com> Cc: davem@...emloft.net, jmorris@...ei.org, kaber@...sh.net, Alexey Kuznetsov <kuznet@....inr.ac.ru>, netdev@...r.kernel.org, pekkas@...core.fi, yoshfuji@...ux-ipv6.org Subject: Re: [PATCH] IPv4 Multicast: prevent reception of mcast frames from unjoined groups On Fri, Jul 11, 2008 at 12:00:57PM -0700, David Stevens wrote: > Yes, that's me, and that's also true. It wasn't the address, it's the time > delay. I think that > was months ago. But you left out a distinguishing piece in your example > here, which is > all the difference. > > Joins are also per-interface. So, joining a group on "lo" does not join > the group on > "eth0". In your example below (4), the reason it won't receive the packets > is because > the machine is not a group member on eth0. If any process joined the group > on eth0 > then an INADDR_ANY-bound socket would receive them (whether it joined or > not). > I guess I wasn't clear -- the reason you have to join below is to > guarantee someone > has joined. If some other process already joined on that interface, you > would > receive them also. > > +-DLS > > Neil Horman <nhorman@...driver.com> wrote on 07/11/2008 11:23:04 AM: > > > > > >>> > > >>> 4) Finally, what if process B bound itself to INADDR_ANY rather than > to > > >>>the > > >>> specific multicast group. Should it see process A's sent frames > then? > > >> > > >> Not if the group membership is on lo and the sends are on > eth0. > > >>The > > >>reason it isn't seeing the packets is not the binding, but the group > > >>membership. To hear packets you're sending out an interface, you must > > >>join that group on that interface *and* the sender must allow loopback > by > > >>not clearing IP_MULTICAST_LOOP. Joining the group on a different > interface > > >>really is joining a different group, as far as multicasting is > concerned. > > > > > But in the sentence above, I think you missed the point of the > > > mail I sent before. Joining a group or not on a particular socket has > > > nothing at all to do with delivery of multicasts to the socket. > > > > > > Multicast addresses, like unicast addresses, are for the > entire > > > machine, not just the socket that does the join. If anyone on the > > > machine has joined the group and your binding matches the packet, you > > > will receive a copy. That's intentional. If you don't join any groups > > > at all, but bind to INADDR_ANY, you will receive packets for the port > > > and protocol and any local unicast or multicast address (including > > > groups joined by any other process on the machine). > > > > > > +-DLS > > > > If thats the final word, then I'll believe you, but it seems to me that > > receiving multicast traffic on a socket that didn't specifically join a > > multicast group is asking for trouble, as every application needs to be > prepared > > to handle data payloads it was not expected to recieve. > > > > Can you clarify your statement above with the one that I copied in from > you > > earlier? > > > > Regards > > Neil > > > > > > -- > > /**************************************************** > > * Neil Horman <nhorman@...driver.com> > > * Software Engineer, Red Hat > > ****************************************************/ Alright, we'll it sounds like this has been well thought out, and my understanding is in the wrong. Patch rescinded. Sorry for the noise. Best Neil -- /**************************************************** * Neil Horman <nhorman@...driver.com> * Software Engineer, Red Hat ****************************************************/ -- 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