From: ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org (Eric W. Biederman)
To: Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: "Serge E. Hallyn" <serge-A9i7LUbDfNHQT0dZR+AlfA@public.gmane.org>,
Aditya Kali <adityakali-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: [PATCH 3/3] cgroupns: Only allow creation of hierarchies in the initial cgroup namespace
Date: Fri, 15 Jul 2016 06:36:44 -0500 [thread overview]
Message-ID: <87h9br16b7.fsf@x220.int.ebiederm.org> (raw)
In-Reply-To: <8760s72lu5.fsf-JOvCrm2gF+uungPnsOpG7nhyD016LWXt@public.gmane.org> (Eric W. Biederman's message of "Fri, 15 Jul 2016 06:16:02 -0500")
Unprivileged users can't use hierarchies if they create them as they do not
have privilieges to the root directory.
Which means the only thing a hiearchy created by an unprivileged user
is good for is expanding the number of cgroup links in every css_set,
which is a DOS attack.
We could allow hierarchies to be created in namespaces in the initial
user namespace. Unfortunately there is only a single namespace for
the names of heirarchies, so that is likely to create more confusion
than not.
So do the simple thing and restrict hiearchy creation to the initial
cgroup namespace.
Cc: stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Fixes: a79a908fd2b0 ("cgroup: introduce cgroup namespaces")
Signed-off-by: "Eric W. Biederman" <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
---
kernel/cgroup.c | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index e75efa819911..e0be49fc382f 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -2215,12 +2215,8 @@ static struct dentry *cgroup_mount(struct file_system_type *fs_type,
goto out_unlock;
}
- /*
- * We know this subsystem has not yet been bound. Users in a non-init
- * user namespace may only mount hierarchies with no bound subsystems,
- * i.e. 'none,name=user1'
- */
- if (!opts.none && !capable(CAP_SYS_ADMIN)) {
+ /* Hierarchies may only be created in the initial cgroup namespace. */
+ if (ns != &init_cgroup_ns) {
ret = -EPERM;
goto out_unlock;
}
--
2.8.3
next prev parent reply other threads:[~2016-07-15 11:36 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <87h9br4h80.fsf@x220.int.ebiederm.org>
[not found] ` <87h9br4h80.fsf-JOvCrm2gF+uungPnsOpG7nhyD016LWXt@public.gmane.org>
2016-07-15 5:15 ` [PATCH 1/3] cgroupns: Fix the locking in copy_cgroup_ns Eric W. Biederman
2016-07-15 5:16 ` [PATCH 2/3] cgroupns: Close race between cgroup_post_fork and copy_cgroup_ns Eric W. Biederman
2016-07-15 5:17 ` [PATCH 3/3] cgroupns: Only allow creation of hierarchies in the initial cgroup namespace Eric W. Biederman
[not found] ` <87r3av32g1.fsf-JOvCrm2gF+uungPnsOpG7nhyD016LWXt@public.gmane.org>
2016-07-15 11:16 ` Tejun Heo
[not found] ` <20160715111659.GB3078-qYNAdHglDFBN0TnZuCh8vA@public.gmane.org>
2016-07-15 11:16 ` Eric W. Biederman
[not found] ` <8760s72lu5.fsf-JOvCrm2gF+uungPnsOpG7nhyD016LWXt@public.gmane.org>
2016-07-15 11:35 ` [PATCH 1/3] cgroupns: Fix the locking in copy_cgroup_ns Eric W. Biederman
2016-07-15 11:35 ` [PATCH 2/3] cgroupns: Close race between cgroup_post_fork and copy_cgroup_ns Eric W. Biederman
[not found] ` <87mvlj16co.fsf_-_-JOvCrm2gF+uungPnsOpG7nhyD016LWXt@public.gmane.org>
2016-07-15 11:58 ` Tejun Heo
2016-07-15 11:36 ` Eric W. Biederman [this message]
[not found] ` <87h9br16b7.fsf-JOvCrm2gF+uungPnsOpG7nhyD016LWXt@public.gmane.org>
2016-07-15 12:05 ` [PATCH 3/3] cgroupns: Only allow creation of hierarchies in the initial cgroup namespace Tejun Heo
[not found] ` <20160715120501.GF3078-qYNAdHglDFBN0TnZuCh8vA@public.gmane.org>
2016-07-15 16:39 ` Serge E. Hallyn
[not found] ` <20160715111847.GC3078@mtj.duckdns.org>
[not found] ` <20160715111847.GC3078-qYNAdHglDFBN0TnZuCh8vA@public.gmane.org>
2016-07-15 11:34 ` [PATCH 0/3] cgroupns: Locking and semantic fixes Eric W. Biederman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87h9br16b7.fsf@x220.int.ebiederm.org \
--to=ebiederm-as9lmozglivwk0htik3j/w@public.gmane.org \
--cc=adityakali-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org \
--cc=cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=serge-A9i7LUbDfNHQT0dZR+AlfA@public.gmane.org \
--cc=tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.