FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor


 
 
LinkBack Thread Tools
 
Old 06-01-2011, 06:57 PM
Serge Hallyn
 
Default CONFIG_NET_NS

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

--
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam
 
Old 06-01-2011, 06:57 PM
Serge Hallyn
 
Default CONFIG_NET_NS

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

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 06-06-2011, 12:58 PM
Tim Gardner
 
Default CONFIG_NET_NS

On 06/01/2011 12:57 PM, Serge Hallyn wrote:

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 is wrong with suggesting the use of LTS backported kernels? The UDS
decision to support these kernels until the next LTS should provide the
same level of stability. We (the kernel team) are very much telling the
community that network name spaces were not ready for prime time in 2.6.32.



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.



It was decided that we should not regress a very common use case (or
package) because of an experimental feature (which CONFIG_NET_NS was in
2.6.32). We were also pretty sure we could not find every existing use
of CLONE_NEWNET, nor prevent future uses of the feature.



Thanks for your time

thanks,
-serge



rtg
--
Tim Gardner tim.gardner@canonical.com

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 06-06-2011, 12:58 PM
Tim Gardner
 
Default CONFIG_NET_NS

On 06/01/2011 12:57 PM, Serge Hallyn wrote:

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 is wrong with suggesting the use of LTS backported kernels? The UDS
decision to support these kernels until the next LTS should provide the
same level of stability. We (the kernel team) are very much telling the
community that network name spaces were not ready for prime time in 2.6.32.



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.



It was decided that we should not regress a very common use case (or
package) because of an experimental feature (which CONFIG_NET_NS was in
2.6.32). We were also pretty sure we could not find every existing use
of CLONE_NEWNET, nor prevent future uses of the feature.



Thanks for your time

thanks,
-serge



rtg
--
Tim Gardner tim.gardner@canonical.com

--
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam
 
Old 06-06-2011, 04:30 PM
Serge Hallyn
 
Default CONFIG_NET_NS

Quoting Tim Gardner (tim.gardner@canonical.com):
> On 06/01/2011 12:57 PM, Serge Hallyn wrote:
> >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 is wrong with suggesting the use of LTS backported kernels? The
> UDS decision to support these kernels until the next LTS should
> provide the same level of stability. We (the kernel team) are very

I guess that depends on how LTS customers feel about "potential of
regressions, but supported" versus "the only updates will be security
updates."

I hadn't realized that the LTS backported kernsl are supported. I
thought it was less formal than that.

I'll leave it sit here, then. Thanks again.

-serge

--
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam
 
Old 06-06-2011, 04:30 PM
Serge Hallyn
 
Default CONFIG_NET_NS

Quoting Tim Gardner (tim.gardner@canonical.com):
> On 06/01/2011 12:57 PM, Serge Hallyn wrote:
> >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 is wrong with suggesting the use of LTS backported kernels? The
> UDS decision to support these kernels until the next LTS should
> provide the same level of stability. We (the kernel team) are very

I guess that depends on how LTS customers feel about "potential of
regressions, but supported" versus "the only updates will be security
updates."

I hadn't realized that the LTS backported kernsl are supported. I
thought it was less formal than that.

I'll leave it sit here, then. Thanks again.

-serge

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 06-07-2011, 12:13 AM
Steve Beattie
 
Default CONFIG_NET_NS

On Mon, Jun 06, 2011 at 11:30:08AM -0500, Serge Hallyn wrote:
> Quoting Tim Gardner (tim.gardner@canonical.com):
> > On 06/01/2011 12:57 PM, Serge Hallyn wrote:
> > >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 is wrong with suggesting the use of LTS backported kernels? The
> > UDS decision to support these kernels until the next LTS should
> > provide the same level of stability. We (the kernel team) are very
>
> I guess that depends on how LTS customers feel about "potential of
> regressions, but supported" versus "the only updates will be security
> updates."
>
> I hadn't realized that the LTS backported kernsl are supported. I
> thought it was less formal than that.
>
> I'll leave it sit here, then. Thanks again.

It was also pointed out[1] by Chris Evans, the author of vsftpd, that
disabling the use of network namespaces by vsftpd just requires setting:

isolate_network=NO

in vsftpd.conf.

Ah, looking at the bug report, it seems you proposed a patch vsftpd to
turn off network isolation (i.e. use of CLONE_NEWNET) by default for
lucid, but then didn't pursue that any further. Perhaps that's the way
forward, to disable by default in vsftpd there and look for additional
sources in the lucid archive that allow a new network namespace to
be triggered by an unprivileged user (as vsftpd does here). The only
downside would be anything outside of the archive that made use of
CLONE_NEWNET could potentially cause the issue to be triggered.

[1] http://www.openwall.com/lists/oss-security/2011/06/06/10

--
Steve Beattie
<sbeattie@ubuntu.com>
http://NxNW.org/~steve/
--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 06-07-2011, 12:13 AM
Steve Beattie
 
Default CONFIG_NET_NS

On Mon, Jun 06, 2011 at 11:30:08AM -0500, Serge Hallyn wrote:
> Quoting Tim Gardner (tim.gardner@canonical.com):
> > On 06/01/2011 12:57 PM, Serge Hallyn wrote:
> > >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 is wrong with suggesting the use of LTS backported kernels? The
> > UDS decision to support these kernels until the next LTS should
> > provide the same level of stability. We (the kernel team) are very
>
> I guess that depends on how LTS customers feel about "potential of
> regressions, but supported" versus "the only updates will be security
> updates."
>
> I hadn't realized that the LTS backported kernsl are supported. I
> thought it was less formal than that.
>
> I'll leave it sit here, then. Thanks again.

It was also pointed out[1] by Chris Evans, the author of vsftpd, that
disabling the use of network namespaces by vsftpd just requires setting:

isolate_network=NO

in vsftpd.conf.

Ah, looking at the bug report, it seems you proposed a patch vsftpd to
turn off network isolation (i.e. use of CLONE_NEWNET) by default for
lucid, but then didn't pursue that any further. Perhaps that's the way
forward, to disable by default in vsftpd there and look for additional
sources in the lucid archive that allow a new network namespace to
be triggered by an unprivileged user (as vsftpd does here). The only
downside would be anything outside of the archive that made use of
CLONE_NEWNET could potentially cause the issue to be triggered.

[1] http://www.openwall.com/lists/oss-security/2011/06/06/10

--
Steve Beattie
<sbeattie@ubuntu.com>
http://NxNW.org/~steve/
--
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam
 

Thread Tools




All times are GMT. The time now is 01:41 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org