From mboxrd@z Thu Jan 1 00:00:00 1970 From: YOSHIFUJI Hideaki Subject: Re: [PATCH 5/9] tproxy: allow non-local binds of IPv6 sockets if IP_TRANSPARENT is enabled Date: Fri, 22 Oct 2010 06:24:12 +0900 Message-ID: <1287696252.2707.24.camel@takos> References: <20101020112118.6260.31618.stgit@este.odu> <20101020112118.6260.93956.stgit@este.odu> <4CBEE45D.2080201@linux-ipv6.org> <1287583653.29676.9.camel@bzorp.lan> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit Cc: KOVACS Krisztian , netdev@vger.kernel.org, netfilter-devel@vger.kernel.org, Patrick McHardy , David Miller , yoshfuji@linux-ipv6.org To: Balazs Scheidler Return-path: Received: from 94.43.138.210.xn.2iij.net ([210.138.43.94]:38535 "EHLO mail.st-paulia.net" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752931Ab0JUVYO (ORCPT ); Thu, 21 Oct 2010 17:24:14 -0400 In-Reply-To: <1287583653.29676.9.camel@bzorp.lan> Sender: netfilter-devel-owner@vger.kernel.org List-ID: Hello. 2010-10-20, Balazs Scheidler wrote: > On Wed, 2010-10-20 at 21:45 +0900, YOSHIFUJI Hideaki wrote: > > (2010/10/20 20:21), KOVACS Krisztian wrote: > > > From: Balazs Scheidler > > > > > > Signed-off-by: Balazs Scheidler > > > Signed-off-by: KOVACS Krisztian > > > --- > > > net/ipv6/af_inet6.c | 2 +- > > > 1 files changed, 1 insertions(+), 1 deletions(-) > > > > > > diff --git a/net/ipv6/af_inet6.c b/net/ipv6/af_inet6.c > > > index 6022098..9480572 100644 > > > --- a/net/ipv6/af_inet6.c > > > +++ b/net/ipv6/af_inet6.c > > > @@ -343,7 +343,7 @@ int inet6_bind(struct socket *sock, struct sockaddr *uaddr, int addr_len) > > > */ > > > v4addr = LOOPBACK4_IPV6; > > > if (!(addr_type& IPV6_ADDR_MULTICAST)) { > > > - if (!ipv6_chk_addr(net,&addr->sin6_addr, > > > + if (!inet->transparent&& !ipv6_chk_addr(net,&addr->sin6_addr, > > > dev, 0)) { > > > err = -EADDRNOTAVAIL; > > > goto out_unlock; > > > > > > > > > > As I wrote before in other thread, this does not seem sufficient -- > > well, it is sufficient to allow non-local bind, but before we're > > allowing this, we need add checks of source address in sending side. > > Can you please elaborate or point us to the other thread? Is it some > kind of address-type check that we miss? Please see my comment at: This will result in allowing non-privileged users easily sending from non-local / unauthorized address, which is not good, and which should not be allowed from security aspects. Regards, --yoshfuji