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