CONFIG_NET_NS
Serge Hallyn
serge.hallyn at canonical.com
Wed Jun 1 18:57:38 UTC 2011
Hi,
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 :)
thanks,
-serge
More information about the ubuntu-server
mailing list