Re: [PATCH review 3/6] userns: Recommend use of memory control groups.
Lord Glauber Costa of Sealand writes: >> For two pieces of software that were designed to complement each other >> I find it a bit surprising how many people (including myself) need the >> connection made that memory control groups and user namespaces should go >> together. > > Well, I've manifested many times in here that I am less than satisfied > about the fact that the connection between namespaces and cgroups are so > loose. There are many situations, like virtualizing the proc files and > friends where I believe we could benefit from having the information > about whether or not cgroups and namespaces are used at the same time. Certainly there are issues where there are not good ways for applications to discover how much memory or how many cpus are available for the application to run on. And applications resort to looking at how much memory or how many cpus are in the box. The only way I can think of to make things better is to provide good alternatives that people can look at and make limiting applications common enough that the bugs start getting fixed. And possibly doing the work to fix a common library or two. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH review 3/6] userns: Recommend use of memory control groups.
On 01/28/2013 08:19 PM, Eric W. Biederman wrote: > Lord Glauber Costa of Sealand writes: > >> On 01/28/2013 12:14 PM, Eric W. Biederman wrote: >>> Lord Glauber Costa of Sealand writes: >>> I just saw in a later patch of yours that your concern here seems not limited to backed ram by tmpfs, but with things like the internal structures for userns , to avoid patterns in the form: 'for (;;) unshare(...)' Humm, it does seem sensible. The kernel memory controller aims to prevent exactly things like that. But they all exist already before userns: there are destructive patterns like that with sockets, dentries, processes, and pretty much every other resource in the kernel. So Although the recommendation per-se makes sense, I am wondering if it is worth it to mention anything in the user_ns config? >>> >>> The config might be overkill. However I have already gotten bug reports >>> about there being no limits. >>> >>> So someone needs to stop and connect the dots and say: >> Absolutely, and I am all for it >> >>> "If you care this is what you can do." >> >> How about we say it, then? >> >> The current text in quite cryptic in this aspect, in the sense that it >> doesn't give enough information for standard people about what are the >> problems involved. >> >> Of course, maybe the Kconfig text is not the best place for having all >> the info: but don't we have some place in Documentation/ where we could >> put this, and then refer people there from Kconfig ? > > At this point I have written the best text I can. > > Please feel free to look at my tree at: > git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git > for-next > Will do soon, thanks for your effort. > and send me an patch on top of that to improve the wording. > > At this point I have done my best to connect the dots for people who > care, that the memory control group is what they need to limit what > people can do with user namespaces. > > My hope is that there is at least a passing mention in the next user > namespace article on lwn. It would definitely be helpful. Let's hope someone from there is reading! =) > > For two pieces of software that were designed to complement each other > I find it a bit surprising how many people (including myself) need the > connection made that memory control groups and user namespaces should go > together. Well, I've manifested many times in here that I am less than satisfied about the fact that the connection between namespaces and cgroups are so loose. There are many situations, like virtualizing the proc files and friends where I believe we could benefit from having the information about whether or not cgroups and namespaces are used at the same time. But since after considering a lot of alternatives, I could never come up with one that were really clean, I guess just communicating it extensively is the best we can do so far. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH review 3/6] userns: Recommend use of memory control groups.
Lord Glauber Costa of Sealand writes: > On 01/28/2013 12:14 PM, Eric W. Biederman wrote: >> Lord Glauber Costa of Sealand writes: >> >>> I just saw in a later patch of yours that your concern here seems not >>> limited to backed ram by tmpfs, but with things like the internal >>> structures for userns , to avoid patterns in the form: 'for (;;) >>> unshare(...)' >>> >>> Humm, it does seem sensible. The kernel memory controller aims to >>> prevent exactly things like that. But they all exist already before >>> userns: there are destructive patterns like that with sockets, dentries, >>> processes, and pretty much every other resource in the kernel. So >>> Although the recommendation per-se makes sense, I am wondering if it is >>> worth it to mention anything in the user_ns config? >> >> The config might be overkill. However I have already gotten bug reports >> about there being no limits. >> >> So someone needs to stop and connect the dots and say: > Absolutely, and I am all for it > >> "If you care this is what you can do." > > How about we say it, then? > > The current text in quite cryptic in this aspect, in the sense that it > doesn't give enough information for standard people about what are the > problems involved. > > Of course, maybe the Kconfig text is not the best place for having all > the info: but don't we have some place in Documentation/ where we could > put this, and then refer people there from Kconfig ? At this point I have written the best text I can. Please feel free to look at my tree at: git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git for-next and send me an patch on top of that to improve the wording. At this point I have done my best to connect the dots for people who care, that the memory control group is what they need to limit what people can do with user namespaces. My hope is that there is at least a passing mention in the next user namespace article on lwn. For two pieces of software that were designed to complement each other I find it a bit surprising how many people (including myself) need the connection made that memory control groups and user namespaces should go together. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH review 3/6] userns: Recommend use of memory control groups.
On 01/28/2013 12:14 PM, Eric W. Biederman wrote: > Lord Glauber Costa of Sealand writes: > >> I just saw in a later patch of yours that your concern here seems not >> limited to backed ram by tmpfs, but with things like the internal >> structures for userns , to avoid patterns in the form: 'for (;;) >> unshare(...)' >> >> Humm, it does seem sensible. The kernel memory controller aims to >> prevent exactly things like that. But they all exist already before >> userns: there are destructive patterns like that with sockets, dentries, >> processes, and pretty much every other resource in the kernel. So >> Although the recommendation per-se makes sense, I am wondering if it is >> worth it to mention anything in the user_ns config? > > The config might be overkill. However I have already gotten bug reports > about there being no limits. > > So someone needs to stop and connect the dots and say: Absolutely, and I am all for it > "If you care this is what you can do." How about we say it, then? The current text in quite cryptic in this aspect, in the sense that it doesn't give enough information for standard people about what are the problems involved. Of course, maybe the Kconfig text is not the best place for having all the info: but don't we have some place in Documentation/ where we could put this, and then refer people there from Kconfig ? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH review 3/6] userns: Recommend use of memory control groups.
Lord Glauber Costa of Sealand writes: > I just saw in a later patch of yours that your concern here seems not > limited to backed ram by tmpfs, but with things like the internal > structures for userns , to avoid patterns in the form: 'for (;;) > unshare(...)' > > Humm, it does seem sensible. The kernel memory controller aims to > prevent exactly things like that. But they all exist already before > userns: there are destructive patterns like that with sockets, dentries, > processes, and pretty much every other resource in the kernel. So > Although the recommendation per-se makes sense, I am wondering if it is > worth it to mention anything in the user_ns config? The config might be overkill. However I have already gotten bug reports about there being no limits. So someone needs to stop and connect the dots and say: "If you care this is what you can do." Especially since the familiar old limits that can kind of sort of prevent memory abuses are not generally available with user namespaces. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH review 3/6] userns: Recommend use of memory control groups.
Lord Glauber Costa of Sealand writes: > On 01/26/2013 06:22 AM, Eric W. Biederman wrote: >> >> In the help text describing user namespaces recommend use of memory >> control groups. In many cases memory control groups are the only >> mechanism there is to limit how much memory a user who can create >> user namespaces can use. >> >> Signed-off-by: "Eric W. Biederman" >> --- >> Documentation/namespaces/resource-control.txt | 10 ++ >> init/Kconfig |7 +++ >> 2 files changed, 17 insertions(+), 0 deletions(-) >> create mode 100644 Documentation/namespaces/resource-control.txt >> >> diff --git a/Documentation/namespaces/resource-control.txt >> b/Documentation/namespaces/resource-control.txt >> new file mode 100644 >> index 000..3d8178a >> --- /dev/null >> +++ b/Documentation/namespaces/resource-control.txt >> @@ -0,0 +1,10 @@ >> +There are a lot of kinds of objects in the kernel that don't have >> +individual limits or that have limits that are ineffective when a set >> +of processes is allowed to switch user ids. With user namespaces >> +enabled in a kernel for people who don't trust their users or their >> +users programs to play nice this problems becomes more acute. >> + >> +Therefore it is recommended that memory control groups be enabled in >> +kernels that enable user namespaces, and it is further recommended >> +that userspace configure memory control groups to limit how much >> +memory users they don't trust to play nice can use. >> diff --git a/init/Kconfig b/init/Kconfig >> index 7d30240..c8c58bd 100644 >> --- a/init/Kconfig >> +++ b/init/Kconfig >> @@ -1035,6 +1035,13 @@ config USER_NS >> help >>This allows containers, i.e. vservers, to use user namespaces >>to provide different user info for different servers. >> + >> + When user namespaces are enabled in the kernel it is >> + recommended that the MEMCG and MEMCG_KMEM options also be >> + enabled and that user-space use the memory control groups to >> + limit the amount of memory a memory unprivileged users can >> + use. >> + >>If unsure, say N. > > Since this becomes an official recommendation that people will likely > follow, are we really that much concerned about the types of abuses the > MEMCG_KMEM will prevent? Those are mostly metadata-based abuses users > could do in their own local disks without mounting anything extra (and > things that look like that) > > Unless there is a specific concern here, shouldn't we say "... that the > MEMCG (and possibly MEMCG_KMEM) options..." ? There are quite a few specific concerns. The easiest to spot is unshare(CLONE_NEWUSER), and the other namespaces. Then there are network devices. Then there is I don't know what else. Most distro's don't seem to care at all about limiting a users memory so in that sense it is not a concern. On the other hand for everyone who wants to limit a user's memory the only way that is going to happen in a reasonable amount of implementation time is with memory control groups, and slabs and kmalloc are most definitely part of the memory needs to be limited. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH review 3/6] userns: Recommend use of memory control groups.
Lord Glauber Costa of Sealand glom...@parallels.com writes: On 01/26/2013 06:22 AM, Eric W. Biederman wrote: In the help text describing user namespaces recommend use of memory control groups. In many cases memory control groups are the only mechanism there is to limit how much memory a user who can create user namespaces can use. Signed-off-by: Eric W. Biederman ebied...@xmission.com --- Documentation/namespaces/resource-control.txt | 10 ++ init/Kconfig |7 +++ 2 files changed, 17 insertions(+), 0 deletions(-) create mode 100644 Documentation/namespaces/resource-control.txt diff --git a/Documentation/namespaces/resource-control.txt b/Documentation/namespaces/resource-control.txt new file mode 100644 index 000..3d8178a --- /dev/null +++ b/Documentation/namespaces/resource-control.txt @@ -0,0 +1,10 @@ +There are a lot of kinds of objects in the kernel that don't have +individual limits or that have limits that are ineffective when a set +of processes is allowed to switch user ids. With user namespaces +enabled in a kernel for people who don't trust their users or their +users programs to play nice this problems becomes more acute. + +Therefore it is recommended that memory control groups be enabled in +kernels that enable user namespaces, and it is further recommended +that userspace configure memory control groups to limit how much +memory users they don't trust to play nice can use. diff --git a/init/Kconfig b/init/Kconfig index 7d30240..c8c58bd 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -1035,6 +1035,13 @@ config USER_NS help This allows containers, i.e. vservers, to use user namespaces to provide different user info for different servers. + + When user namespaces are enabled in the kernel it is + recommended that the MEMCG and MEMCG_KMEM options also be + enabled and that user-space use the memory control groups to + limit the amount of memory a memory unprivileged users can + use. + If unsure, say N. Since this becomes an official recommendation that people will likely follow, are we really that much concerned about the types of abuses the MEMCG_KMEM will prevent? Those are mostly metadata-based abuses users could do in their own local disks without mounting anything extra (and things that look like that) Unless there is a specific concern here, shouldn't we say ... that the MEMCG (and possibly MEMCG_KMEM) options... ? There are quite a few specific concerns. The easiest to spot is unshare(CLONE_NEWUSER), and the other namespaces. Then there are network devices. Then there is I don't know what else. Most distro's don't seem to care at all about limiting a users memory so in that sense it is not a concern. On the other hand for everyone who wants to limit a user's memory the only way that is going to happen in a reasonable amount of implementation time is with memory control groups, and slabs and kmalloc are most definitely part of the memory needs to be limited. Eric -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH review 3/6] userns: Recommend use of memory control groups.
Lord Glauber Costa of Sealand glom...@parallels.com writes: I just saw in a later patch of yours that your concern here seems not limited to backed ram by tmpfs, but with things like the internal structures for userns , to avoid patterns in the form: 'for (;;) unshare(...)' Humm, it does seem sensible. The kernel memory controller aims to prevent exactly things like that. But they all exist already before userns: there are destructive patterns like that with sockets, dentries, processes, and pretty much every other resource in the kernel. So Although the recommendation per-se makes sense, I am wondering if it is worth it to mention anything in the user_ns config? The config might be overkill. However I have already gotten bug reports about there being no limits. So someone needs to stop and connect the dots and say: If you care this is what you can do. Especially since the familiar old limits that can kind of sort of prevent memory abuses are not generally available with user namespaces. Eric -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH review 3/6] userns: Recommend use of memory control groups.
On 01/28/2013 12:14 PM, Eric W. Biederman wrote: Lord Glauber Costa of Sealand glom...@parallels.com writes: I just saw in a later patch of yours that your concern here seems not limited to backed ram by tmpfs, but with things like the internal structures for userns , to avoid patterns in the form: 'for (;;) unshare(...)' Humm, it does seem sensible. The kernel memory controller aims to prevent exactly things like that. But they all exist already before userns: there are destructive patterns like that with sockets, dentries, processes, and pretty much every other resource in the kernel. So Although the recommendation per-se makes sense, I am wondering if it is worth it to mention anything in the user_ns config? The config might be overkill. However I have already gotten bug reports about there being no limits. So someone needs to stop and connect the dots and say: Absolutely, and I am all for it If you care this is what you can do. How about we say it, then? The current text in quite cryptic in this aspect, in the sense that it doesn't give enough information for standard people about what are the problems involved. Of course, maybe the Kconfig text is not the best place for having all the info: but don't we have some place in Documentation/ where we could put this, and then refer people there from Kconfig ? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH review 3/6] userns: Recommend use of memory control groups.
Lord Glauber Costa of Sealand glom...@parallels.com writes: On 01/28/2013 12:14 PM, Eric W. Biederman wrote: Lord Glauber Costa of Sealand glom...@parallels.com writes: I just saw in a later patch of yours that your concern here seems not limited to backed ram by tmpfs, but with things like the internal structures for userns , to avoid patterns in the form: 'for (;;) unshare(...)' Humm, it does seem sensible. The kernel memory controller aims to prevent exactly things like that. But they all exist already before userns: there are destructive patterns like that with sockets, dentries, processes, and pretty much every other resource in the kernel. So Although the recommendation per-se makes sense, I am wondering if it is worth it to mention anything in the user_ns config? The config might be overkill. However I have already gotten bug reports about there being no limits. So someone needs to stop and connect the dots and say: Absolutely, and I am all for it If you care this is what you can do. How about we say it, then? The current text in quite cryptic in this aspect, in the sense that it doesn't give enough information for standard people about what are the problems involved. Of course, maybe the Kconfig text is not the best place for having all the info: but don't we have some place in Documentation/ where we could put this, and then refer people there from Kconfig ? At this point I have written the best text I can. Please feel free to look at my tree at: git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git for-next and send me an patch on top of that to improve the wording. At this point I have done my best to connect the dots for people who care, that the memory control group is what they need to limit what people can do with user namespaces. My hope is that there is at least a passing mention in the next user namespace article on lwn. For two pieces of software that were designed to complement each other I find it a bit surprising how many people (including myself) need the connection made that memory control groups and user namespaces should go together. Eric -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH review 3/6] userns: Recommend use of memory control groups.
On 01/28/2013 08:19 PM, Eric W. Biederman wrote: Lord Glauber Costa of Sealand glom...@parallels.com writes: On 01/28/2013 12:14 PM, Eric W. Biederman wrote: Lord Glauber Costa of Sealand glom...@parallels.com writes: I just saw in a later patch of yours that your concern here seems not limited to backed ram by tmpfs, but with things like the internal structures for userns , to avoid patterns in the form: 'for (;;) unshare(...)' Humm, it does seem sensible. The kernel memory controller aims to prevent exactly things like that. But they all exist already before userns: there are destructive patterns like that with sockets, dentries, processes, and pretty much every other resource in the kernel. So Although the recommendation per-se makes sense, I am wondering if it is worth it to mention anything in the user_ns config? The config might be overkill. However I have already gotten bug reports about there being no limits. So someone needs to stop and connect the dots and say: Absolutely, and I am all for it If you care this is what you can do. How about we say it, then? The current text in quite cryptic in this aspect, in the sense that it doesn't give enough information for standard people about what are the problems involved. Of course, maybe the Kconfig text is not the best place for having all the info: but don't we have some place in Documentation/ where we could put this, and then refer people there from Kconfig ? At this point I have written the best text I can. Please feel free to look at my tree at: git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git for-next Will do soon, thanks for your effort. and send me an patch on top of that to improve the wording. At this point I have done my best to connect the dots for people who care, that the memory control group is what they need to limit what people can do with user namespaces. My hope is that there is at least a passing mention in the next user namespace article on lwn. It would definitely be helpful. Let's hope someone from there is reading! =) For two pieces of software that were designed to complement each other I find it a bit surprising how many people (including myself) need the connection made that memory control groups and user namespaces should go together. Well, I've manifested many times in here that I am less than satisfied about the fact that the connection between namespaces and cgroups are so loose. There are many situations, like virtualizing the proc files and friends where I believe we could benefit from having the information about whether or not cgroups and namespaces are used at the same time. But since after considering a lot of alternatives, I could never come up with one that were really clean, I guess just communicating it extensively is the best we can do so far. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH review 3/6] userns: Recommend use of memory control groups.
Lord Glauber Costa of Sealand glom...@parallels.com writes: For two pieces of software that were designed to complement each other I find it a bit surprising how many people (including myself) need the connection made that memory control groups and user namespaces should go together. Well, I've manifested many times in here that I am less than satisfied about the fact that the connection between namespaces and cgroups are so loose. There are many situations, like virtualizing the proc files and friends where I believe we could benefit from having the information about whether or not cgroups and namespaces are used at the same time. Certainly there are issues where there are not good ways for applications to discover how much memory or how many cpus are available for the application to run on. And applications resort to looking at how much memory or how many cpus are in the box. The only way I can think of to make things better is to provide good alternatives that people can look at and make limiting applications common enough that the bugs start getting fixed. And possibly doing the work to fix a common library or two. Eric -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH review 3/6] userns: Recommend use of memory control groups.
On 01/28/2013 11:37 AM, Lord Glauber Costa of Sealand wrote: > On 01/26/2013 06:22 AM, Eric W. Biederman wrote: >> >> In the help text describing user namespaces recommend use of memory >> control groups. In many cases memory control groups are the only >> mechanism there is to limit how much memory a user who can create >> user namespaces can use. >> >> Signed-off-by: "Eric W. Biederman" >> --- >> Documentation/namespaces/resource-control.txt | 10 ++ >> init/Kconfig |7 +++ >> 2 files changed, 17 insertions(+), 0 deletions(-) >> create mode 100644 Documentation/namespaces/resource-control.txt >> >> diff --git a/Documentation/namespaces/resource-control.txt >> b/Documentation/namespaces/resource-control.txt >> new file mode 100644 >> index 000..3d8178a >> --- /dev/null >> +++ b/Documentation/namespaces/resource-control.txt >> @@ -0,0 +1,10 @@ >> +There are a lot of kinds of objects in the kernel that don't have >> +individual limits or that have limits that are ineffective when a set >> +of processes is allowed to switch user ids. With user namespaces >> +enabled in a kernel for people who don't trust their users or their >> +users programs to play nice this problems becomes more acute. >> + >> +Therefore it is recommended that memory control groups be enabled in >> +kernels that enable user namespaces, and it is further recommended >> +that userspace configure memory control groups to limit how much >> +memory users they don't trust to play nice can use. >> diff --git a/init/Kconfig b/init/Kconfig >> index 7d30240..c8c58bd 100644 >> --- a/init/Kconfig >> +++ b/init/Kconfig >> @@ -1035,6 +1035,13 @@ config USER_NS >> help >>This allows containers, i.e. vservers, to use user namespaces >>to provide different user info for different servers. >> + >> + When user namespaces are enabled in the kernel it is >> + recommended that the MEMCG and MEMCG_KMEM options also be >> + enabled and that user-space use the memory control groups to >> + limit the amount of memory a memory unprivileged users can >> + use. >> + >>If unsure, say N. > > Since this becomes an official recommendation that people will likely > follow, are we really that much concerned about the types of abuses the > MEMCG_KMEM will prevent? Those are mostly metadata-based abuses users > could do in their own local disks without mounting anything extra (and > things that look like that) > > Unless there is a specific concern here, shouldn't we say "... that the > MEMCG (and possibly MEMCG_KMEM) options..." ? > > I just saw in a later patch of yours that your concern here seems not limited to backed ram by tmpfs, but with things like the internal structures for userns , to avoid patterns in the form: 'for (;;) unshare(...)' Humm, it does seem sensible. The kernel memory controller aims to prevent exactly things like that. But they all exist already before userns: there are destructive patterns like that with sockets, dentries, processes, and pretty much every other resource in the kernel. So Although the recommendation per-se makes sense, I am wondering if it is worth it to mention anything in the user_ns config? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH review 3/6] userns: Recommend use of memory control groups.
On 01/26/2013 06:22 AM, Eric W. Biederman wrote: > > In the help text describing user namespaces recommend use of memory > control groups. In many cases memory control groups are the only > mechanism there is to limit how much memory a user who can create > user namespaces can use. > > Signed-off-by: "Eric W. Biederman" > --- > Documentation/namespaces/resource-control.txt | 10 ++ > init/Kconfig |7 +++ > 2 files changed, 17 insertions(+), 0 deletions(-) > create mode 100644 Documentation/namespaces/resource-control.txt > > diff --git a/Documentation/namespaces/resource-control.txt > b/Documentation/namespaces/resource-control.txt > new file mode 100644 > index 000..3d8178a > --- /dev/null > +++ b/Documentation/namespaces/resource-control.txt > @@ -0,0 +1,10 @@ > +There are a lot of kinds of objects in the kernel that don't have > +individual limits or that have limits that are ineffective when a set > +of processes is allowed to switch user ids. With user namespaces > +enabled in a kernel for people who don't trust their users or their > +users programs to play nice this problems becomes more acute. > + > +Therefore it is recommended that memory control groups be enabled in > +kernels that enable user namespaces, and it is further recommended > +that userspace configure memory control groups to limit how much > +memory users they don't trust to play nice can use. > diff --git a/init/Kconfig b/init/Kconfig > index 7d30240..c8c58bd 100644 > --- a/init/Kconfig > +++ b/init/Kconfig > @@ -1035,6 +1035,13 @@ config USER_NS > help > This allows containers, i.e. vservers, to use user namespaces > to provide different user info for different servers. > + > + When user namespaces are enabled in the kernel it is > + recommended that the MEMCG and MEMCG_KMEM options also be > + enabled and that user-space use the memory control groups to > + limit the amount of memory a memory unprivileged users can > + use. > + > If unsure, say N. Since this becomes an official recommendation that people will likely follow, are we really that much concerned about the types of abuses the MEMCG_KMEM will prevent? Those are mostly metadata-based abuses users could do in their own local disks without mounting anything extra (and things that look like that) Unless there is a specific concern here, shouldn't we say "... that the MEMCG (and possibly MEMCG_KMEM) options..." ? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH review 3/6] userns: Recommend use of memory control groups.
On 01/26/2013 06:22 AM, Eric W. Biederman wrote: In the help text describing user namespaces recommend use of memory control groups. In many cases memory control groups are the only mechanism there is to limit how much memory a user who can create user namespaces can use. Signed-off-by: Eric W. Biederman ebied...@xmission.com --- Documentation/namespaces/resource-control.txt | 10 ++ init/Kconfig |7 +++ 2 files changed, 17 insertions(+), 0 deletions(-) create mode 100644 Documentation/namespaces/resource-control.txt diff --git a/Documentation/namespaces/resource-control.txt b/Documentation/namespaces/resource-control.txt new file mode 100644 index 000..3d8178a --- /dev/null +++ b/Documentation/namespaces/resource-control.txt @@ -0,0 +1,10 @@ +There are a lot of kinds of objects in the kernel that don't have +individual limits or that have limits that are ineffective when a set +of processes is allowed to switch user ids. With user namespaces +enabled in a kernel for people who don't trust their users or their +users programs to play nice this problems becomes more acute. + +Therefore it is recommended that memory control groups be enabled in +kernels that enable user namespaces, and it is further recommended +that userspace configure memory control groups to limit how much +memory users they don't trust to play nice can use. diff --git a/init/Kconfig b/init/Kconfig index 7d30240..c8c58bd 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -1035,6 +1035,13 @@ config USER_NS help This allows containers, i.e. vservers, to use user namespaces to provide different user info for different servers. + + When user namespaces are enabled in the kernel it is + recommended that the MEMCG and MEMCG_KMEM options also be + enabled and that user-space use the memory control groups to + limit the amount of memory a memory unprivileged users can + use. + If unsure, say N. Since this becomes an official recommendation that people will likely follow, are we really that much concerned about the types of abuses the MEMCG_KMEM will prevent? Those are mostly metadata-based abuses users could do in their own local disks without mounting anything extra (and things that look like that) Unless there is a specific concern here, shouldn't we say ... that the MEMCG (and possibly MEMCG_KMEM) options... ? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH review 3/6] userns: Recommend use of memory control groups.
On 01/28/2013 11:37 AM, Lord Glauber Costa of Sealand wrote: On 01/26/2013 06:22 AM, Eric W. Biederman wrote: In the help text describing user namespaces recommend use of memory control groups. In many cases memory control groups are the only mechanism there is to limit how much memory a user who can create user namespaces can use. Signed-off-by: Eric W. Biederman ebied...@xmission.com --- Documentation/namespaces/resource-control.txt | 10 ++ init/Kconfig |7 +++ 2 files changed, 17 insertions(+), 0 deletions(-) create mode 100644 Documentation/namespaces/resource-control.txt diff --git a/Documentation/namespaces/resource-control.txt b/Documentation/namespaces/resource-control.txt new file mode 100644 index 000..3d8178a --- /dev/null +++ b/Documentation/namespaces/resource-control.txt @@ -0,0 +1,10 @@ +There are a lot of kinds of objects in the kernel that don't have +individual limits or that have limits that are ineffective when a set +of processes is allowed to switch user ids. With user namespaces +enabled in a kernel for people who don't trust their users or their +users programs to play nice this problems becomes more acute. + +Therefore it is recommended that memory control groups be enabled in +kernels that enable user namespaces, and it is further recommended +that userspace configure memory control groups to limit how much +memory users they don't trust to play nice can use. diff --git a/init/Kconfig b/init/Kconfig index 7d30240..c8c58bd 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -1035,6 +1035,13 @@ config USER_NS help This allows containers, i.e. vservers, to use user namespaces to provide different user info for different servers. + + When user namespaces are enabled in the kernel it is + recommended that the MEMCG and MEMCG_KMEM options also be + enabled and that user-space use the memory control groups to + limit the amount of memory a memory unprivileged users can + use. + If unsure, say N. Since this becomes an official recommendation that people will likely follow, are we really that much concerned about the types of abuses the MEMCG_KMEM will prevent? Those are mostly metadata-based abuses users could do in their own local disks without mounting anything extra (and things that look like that) Unless there is a specific concern here, shouldn't we say ... that the MEMCG (and possibly MEMCG_KMEM) options... ? I just saw in a later patch of yours that your concern here seems not limited to backed ram by tmpfs, but with things like the internal structures for userns , to avoid patterns in the form: 'for (;;) unshare(...)' Humm, it does seem sensible. The kernel memory controller aims to prevent exactly things like that. But they all exist already before userns: there are destructive patterns like that with sockets, dentries, processes, and pretty much every other resource in the kernel. So Although the recommendation per-se makes sense, I am wondering if it is worth it to mention anything in the user_ns config? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH review 3/6] userns: Recommend use of memory control groups.
"Serge E. Hallyn" writes: > Quoting Eric W. Biederman (ebied...@xmission.com): >> >> In the help text describing user namespaces recommend use of memory >> control groups. In many cases memory control groups are the only >> mechanism there is to limit how much memory a user who can create >> user namespaces can use. >> >> Signed-off-by: "Eric W. Biederman" > > Acked-by: Serge Hallyn > > nit: > I have fixed you nit and added the following text, so people know have a clue where to look to configure cgroups in userspace. diff --git a/Documentation/namespaces/resource-control.txt b/Documentation/namespaces/resource-control.txt index 3d8178a..abc13c3 100644 --- a/Documentation/namespaces/resource-control.txt +++ b/Documentation/namespaces/resource-control.txt @@ -7,4 +7,8 @@ users programs to play nice this problems becomes more acute. Therefore it is recommended that memory control groups be enabled in kernels that enable user namespaces, and it is further recommended that userspace configure memory control groups to limit how much -memory users they don't trust to play nice can use. +memory user's they don't trust to play nice can use. + +Memory control groups can be configured by installing the libcgroup +package present on most distros editing /etc/cgrules.conf, +/etc/cgconfig.conf and setting up libpam-cgroup. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH review 3/6] userns: Recommend use of memory control groups.
Quoting Eric W. Biederman (ebied...@xmission.com): > > In the help text describing user namespaces recommend use of memory > control groups. In many cases memory control groups are the only > mechanism there is to limit how much memory a user who can create > user namespaces can use. > > Signed-off-by: "Eric W. Biederman" Acked-by: Serge Hallyn nit: > --- > Documentation/namespaces/resource-control.txt | 10 ++ > init/Kconfig |7 +++ > 2 files changed, 17 insertions(+), 0 deletions(-) > create mode 100644 Documentation/namespaces/resource-control.txt > > diff --git a/Documentation/namespaces/resource-control.txt > b/Documentation/namespaces/resource-control.txt > new file mode 100644 > index 000..3d8178a > --- /dev/null > +++ b/Documentation/namespaces/resource-control.txt > @@ -0,0 +1,10 @@ > +There are a lot of kinds of objects in the kernel that don't have > +individual limits or that have limits that are ineffective when a set > +of processes is allowed to switch user ids. With user namespaces > +enabled in a kernel for people who don't trust their users or their > +users programs to play nice this problems becomes more acute. users' programs > + > +Therefore it is recommended that memory control groups be enabled in > +kernels that enable user namespaces, and it is further recommended > +that userspace configure memory control groups to limit how much > +memory users they don't trust to play nice can use. > diff --git a/init/Kconfig b/init/Kconfig > index 7d30240..c8c58bd 100644 > --- a/init/Kconfig > +++ b/init/Kconfig > @@ -1035,6 +1035,13 @@ config USER_NS > help > This allows containers, i.e. vservers, to use user namespaces > to provide different user info for different servers. > + > + When user namespaces are enabled in the kernel it is > + recommended that the MEMCG and MEMCG_KMEM options also be > + enabled and that user-space use the memory control groups to > + limit the amount of memory a memory unprivileged users can > + use. > + > If unsure, say N. > > config PID_NS > -- > 1.7.5.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH review 3/6] userns: Recommend use of memory control groups.
Quoting Eric W. Biederman (ebied...@xmission.com): In the help text describing user namespaces recommend use of memory control groups. In many cases memory control groups are the only mechanism there is to limit how much memory a user who can create user namespaces can use. Signed-off-by: Eric W. Biederman ebied...@xmission.com Acked-by: Serge Hallyn serge.hal...@canonical.com nit: --- Documentation/namespaces/resource-control.txt | 10 ++ init/Kconfig |7 +++ 2 files changed, 17 insertions(+), 0 deletions(-) create mode 100644 Documentation/namespaces/resource-control.txt diff --git a/Documentation/namespaces/resource-control.txt b/Documentation/namespaces/resource-control.txt new file mode 100644 index 000..3d8178a --- /dev/null +++ b/Documentation/namespaces/resource-control.txt @@ -0,0 +1,10 @@ +There are a lot of kinds of objects in the kernel that don't have +individual limits or that have limits that are ineffective when a set +of processes is allowed to switch user ids. With user namespaces +enabled in a kernel for people who don't trust their users or their +users programs to play nice this problems becomes more acute. users' programs + +Therefore it is recommended that memory control groups be enabled in +kernels that enable user namespaces, and it is further recommended +that userspace configure memory control groups to limit how much +memory users they don't trust to play nice can use. diff --git a/init/Kconfig b/init/Kconfig index 7d30240..c8c58bd 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -1035,6 +1035,13 @@ config USER_NS help This allows containers, i.e. vservers, to use user namespaces to provide different user info for different servers. + + When user namespaces are enabled in the kernel it is + recommended that the MEMCG and MEMCG_KMEM options also be + enabled and that user-space use the memory control groups to + limit the amount of memory a memory unprivileged users can + use. + If unsure, say N. config PID_NS -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH review 3/6] userns: Recommend use of memory control groups.
Serge E. Hallyn se...@hallyn.com writes: Quoting Eric W. Biederman (ebied...@xmission.com): In the help text describing user namespaces recommend use of memory control groups. In many cases memory control groups are the only mechanism there is to limit how much memory a user who can create user namespaces can use. Signed-off-by: Eric W. Biederman ebied...@xmission.com Acked-by: Serge Hallyn serge.hal...@canonical.com nit: I have fixed you nit and added the following text, so people know have a clue where to look to configure cgroups in userspace. diff --git a/Documentation/namespaces/resource-control.txt b/Documentation/namespaces/resource-control.txt index 3d8178a..abc13c3 100644 --- a/Documentation/namespaces/resource-control.txt +++ b/Documentation/namespaces/resource-control.txt @@ -7,4 +7,8 @@ users programs to play nice this problems becomes more acute. Therefore it is recommended that memory control groups be enabled in kernels that enable user namespaces, and it is further recommended that userspace configure memory control groups to limit how much -memory users they don't trust to play nice can use. +memory user's they don't trust to play nice can use. + +Memory control groups can be configured by installing the libcgroup +package present on most distros editing /etc/cgrules.conf, +/etc/cgconfig.conf and setting up libpam-cgroup. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH review 3/6] userns: Recommend use of memory control groups.
In the help text describing user namespaces recommend use of memory control groups. In many cases memory control groups are the only mechanism there is to limit how much memory a user who can create user namespaces can use. Signed-off-by: "Eric W. Biederman" --- Documentation/namespaces/resource-control.txt | 10 ++ init/Kconfig |7 +++ 2 files changed, 17 insertions(+), 0 deletions(-) create mode 100644 Documentation/namespaces/resource-control.txt diff --git a/Documentation/namespaces/resource-control.txt b/Documentation/namespaces/resource-control.txt new file mode 100644 index 000..3d8178a --- /dev/null +++ b/Documentation/namespaces/resource-control.txt @@ -0,0 +1,10 @@ +There are a lot of kinds of objects in the kernel that don't have +individual limits or that have limits that are ineffective when a set +of processes is allowed to switch user ids. With user namespaces +enabled in a kernel for people who don't trust their users or their +users programs to play nice this problems becomes more acute. + +Therefore it is recommended that memory control groups be enabled in +kernels that enable user namespaces, and it is further recommended +that userspace configure memory control groups to limit how much +memory users they don't trust to play nice can use. diff --git a/init/Kconfig b/init/Kconfig index 7d30240..c8c58bd 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -1035,6 +1035,13 @@ config USER_NS help This allows containers, i.e. vservers, to use user namespaces to provide different user info for different servers. + + When user namespaces are enabled in the kernel it is + recommended that the MEMCG and MEMCG_KMEM options also be + enabled and that user-space use the memory control groups to + limit the amount of memory a memory unprivileged users can + use. + If unsure, say N. config PID_NS -- 1.7.5.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH review 3/6] userns: Recommend use of memory control groups.
In the help text describing user namespaces recommend use of memory control groups. In many cases memory control groups are the only mechanism there is to limit how much memory a user who can create user namespaces can use. Signed-off-by: Eric W. Biederman ebied...@xmission.com --- Documentation/namespaces/resource-control.txt | 10 ++ init/Kconfig |7 +++ 2 files changed, 17 insertions(+), 0 deletions(-) create mode 100644 Documentation/namespaces/resource-control.txt diff --git a/Documentation/namespaces/resource-control.txt b/Documentation/namespaces/resource-control.txt new file mode 100644 index 000..3d8178a --- /dev/null +++ b/Documentation/namespaces/resource-control.txt @@ -0,0 +1,10 @@ +There are a lot of kinds of objects in the kernel that don't have +individual limits or that have limits that are ineffective when a set +of processes is allowed to switch user ids. With user namespaces +enabled in a kernel for people who don't trust their users or their +users programs to play nice this problems becomes more acute. + +Therefore it is recommended that memory control groups be enabled in +kernels that enable user namespaces, and it is further recommended +that userspace configure memory control groups to limit how much +memory users they don't trust to play nice can use. diff --git a/init/Kconfig b/init/Kconfig index 7d30240..c8c58bd 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -1035,6 +1035,13 @@ config USER_NS help This allows containers, i.e. vservers, to use user namespaces to provide different user info for different servers. + + When user namespaces are enabled in the kernel it is + recommended that the MEMCG and MEMCG_KMEM options also be + enabled and that user-space use the memory control groups to + limit the amount of memory a memory unprivileged users can + use. + If unsure, say N. config PID_NS -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
