The bug is described by Serge Hallyn below, and in Ubuntu bug #720095
In short, I agree with Serge that the network namespace feature in the
kernel is useful and should be retained in squeeze, given that only
privileged users can (directly) use it. vsftpd must not create a
network namespace per connection without a kernel version check.
-------- Forwarded Message --------
From: Serge Hallyn <email@example.com>
To: firstname.lastname@example.org, email@example.com
Date: Wed, 1 Jun 2011 13:57:38 -0500
vsftpd spawns a network namespace in response to each client connection.
Lucid kernel is slow to release network namespaces, which results, in
bug 720095, in an easy remote DOS. The maverick kernel has a fix for
this, but it is hard to cherrypick.
The bug was resolved by compiling the lucid kernel without
CONFIG_NET_NS. I'm emailing to ask that we reconsider that solution.
Turning off CONFIG_NET_NS prevents libvirt from creating all containers
(lxc:///), and prevents lxc from creating most useful containers,
resulting in bug 790863. There is the workaround of installing the
backported kernel, but I don't believe that will satiate users who
really want LTS stability. For those users, we are effectively telling
them that they cannot use containers until 12/04.
What I don't believe has been discussed is that CLONE_NEWNET requires
privilege. The vsftpd bug was bad because anyone could trigger it with
a set of remote connections. But that is easily fixed by patching
vsftpd to not use CLONE_NEWNET. As Stefan noted in irc, there is the
threat that other services use CLONE_NEWNET. Though I've grepped some
of my local sources for samba, dhclient, postfix, apache, mysql, squid
etc, and have found no others using CLONE_NEWNET so far. That doesn't
mean there aren't any, but I argue that the risk is far outweighed by
not supporting containers in lucid.
Thanks for your time
kernel-team mailing list
Once a job is fouled up, anything done to improve it makes it worse.