netdev - Re: 2.6.29 regression? Bonding tied to IPV6 in 29-rc5

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1234992067.7692.38.camel@Maple>
Date:	Wed, 18 Feb 2009 21:21:07 +0000
From:	John Dykstra <john.dykstra1@...il.com>
To:	Brian Haley <brian.haley@...com>
Cc:	David Miller <davem@...emloft.net>,
	YOSHIFUJI Hideaki <yoshfuji@...ux-ipv6.org>,
	Vlad Yasevich <vladislav.yasevich@...com>,
	Chuck Lever <chuck.lever@...cle.com>,
	Theodore Tso <tytso@....edu>, Valdis.Kletnieks@...edu,
	arvidjaar@...l.ru, rjw@...k.pl, netdev@...r.kernel.org,
	bonding-devel@...ts.sourceforge.net, jamagallon@....com,
	linux-kernel@...r.kernel.org
Subject: Re: 2.6.29 regression? Bonding tied to IPV6 in 29-rc5

On Wed, 2009-02-18 at 14:57 -0500, Brian Haley wrote: 
> Vlad Yasevich wrote:
> > Having worked in other environments where ipv6 has to be explicitly
> > enabled per interface, I've thought that this level of control was
> > always missing from linux.  
> 
> There does seem to be a sysctl for it, just doesn't seem to work.

While this sysctl is definitely useful, I don't think it meets the needs
of those users and distributions that are currently blacklisting the
ipv6 module.  Even if you disable IPv6 on all interfaces, apps will
still be able to create AF_INET6 sockets, and thus some apps will break
or do inappropriate things because there isn't real IPv6 connectivity.

I've tried to put together an RFC patch that turned off all
externally-visible IPv6 behavior that could break something, but I keep
running into distasteful choices.

The current default behavior must be preserved--if you drop this patch
into an existing distribution, the IPv6 stack must come up the way it
always has.  Thus the knob (let's call it ip6_disable) must default
false.

It seems desirable to make this a per-net-namespace knob.  But that
means each new net will be initialized before the distribution has a
chance to disable the IPv6 part.  This will lead to neighbor solicits
going out for link-local addresses, which some people can't accept.

The only alternative I can think of is to make it a module parameter,
which would leverage people's current habit to disable IPv6 via the
module configuration files, but doesn't fit well into a virtualized
world.

Exactly what to disable is unclear too.  Turning off neighbor and router
solicits, responding to same, etc.--almost certainly.  Refusing to
create AF_INET6 sockets--definitely.  Erroring on ioctl() and netlink
API calls related to IPv6--probably.  Hiding /proc entries for IPv6--I
don't know.  

Ideally, once ip6_disable was set true, every API, /proc and /sys
entries, etc. would look just like the ipv6 module was not loaded.  But
to do this, while still initializing most of the IPv6 code (so that
those hooks from other modules won't do unexpected things) is very
invasive.

So it seems to me that the only practical solution is to live with
blacklisting module ipv6 until the apps are fixed and sending IPv6
packets isn't considered a crime.

  --  John

--
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