Received: by 10.223.164.202 with SMTP id h10csp194776wrb; Sat, 25 Nov 2017 22:41:30 -0800 (PST) X-Google-Smtp-Source: AGs4zMbpEcbozF6kUfIqWESfc7BTNHXDmocSoyqXUBnWERSRsW7HbVxZYIEHPBdAChBDh2BOzwUB X-Received: by 10.101.92.74 with SMTP id v10mr2068536pgr.193.1511678490399; Sat, 25 Nov 2017 22:41:30 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1511678490; cv=none; d=google.com; s=arc-20160816; b=Fq4dXNWQRsS+kkV1mZlaUw9UhMsXzPKfeM4YZQ2vxb+Bm36t9dPuv+qHf+iDjp9pA9 B9oRKdFmYhRMqdoO5cV1ZCINQvNKkiLD5ft2bClfGc7su3tvieZf6S2fNCAR+8DEUcnv QiYIWMhdR/KjK1nTOKg4e5PHNPqq3LhJicGZ53qogKOcHnMx/Lbl2PFrMFg9CkLc7uBg ll1/U8waxNnDURbVmG8Iip6ZkxkDr54kHofP0M7GL2JR2J9xQD9SK+zCQiYiEK28B87W EMVameTG9xR8Y2ldAs5lHOylslC8JEGP5c0rPf4cWW4MmSjWJilVBwU5mGDXAX77Cvsi 84hQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=6JmHlQi/+Qq0l69e/TvnZbejpef8drzi/1/5N8CVqJs=; b=WstHUj+CRrBINcd0Cv3Q7ygqPjwspx2q3Ro5slV/tW4g4otU787Zo6Tys4RLZksRqg E4kKSVqmArEY2VbeqVl+PeCqFBRbfw84Wfo2C2V27nr8UXvhkHCiFWJA3dGeAN2TUKjB SRNOJEdWTkeQXsU3LckRLY6Z5897WilytCnIgkIk71rTqdxC7Se0qRaODl4Ma1DNptNn k2zdFOQjG6zi29NmcxH+LgY6a3CC0CjNYY2KfabFLPhSCZnUFt6Mq/+d3cxSquNdcyDX HHClCg65Th3i3D/R1ErcNUfDPtKeiFw8nRI3HlRHH6hR6yKDkVXBym5RbK/n1U0f7LBJ 4qyA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id o24si21755031pll.390.2017.11.25.22.41.18; Sat, 25 Nov 2017 22:41:30 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752071AbdKZGkl (ORCPT + 80 others); Sun, 26 Nov 2017 01:40:41 -0500 Received: from h2.hallyn.com ([78.46.35.8]:37866 "EHLO h2.hallyn.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751628AbdKZGkj (ORCPT ); Sun, 26 Nov 2017 01:40:39 -0500 Received: by h2.hallyn.com (Postfix, from userid 1001) id 011D612041C; Sun, 26 Nov 2017 00:40:37 -0600 (CST) Date: Sun, 26 Nov 2017 00:40:37 -0600 From: "Serge E. Hallyn" To: Mahesh Bandewar Cc: LKML , Netdev , Kernel-hardening , Linux API , Kees Cook , Serge Hallyn , "Eric W . Biederman" , Eric Dumazet , David Miller , Mahesh Bandewar Subject: Re: [PATCHv2 2/2] userns: control capabilities of some user namespaces Message-ID: <20171126064037.GB30279@mail.hallyn.com> References: <20171110053757.21170-1-mahesh@bandewar.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171110053757.21170-1-mahesh@bandewar.net> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Quoting Mahesh Bandewar (mahesh@bandewar.net): > From: Mahesh Bandewar > > With this new notion of "controlled" user-namespaces, the controlled > user-namespaces are marked at the time of their creation while the > capabilities of processes that belong to them are controlled using the > global mask. > > Init-user-ns is always uncontrolled and a process that has SYS_ADMIN > that belongs to uncontrolled user-ns can create another (child) user- > namespace that is uncontrolled. Any other process (that either does > not have SYS_ADMIN or belongs to a controlled user-ns) can only > create a user-ns that is controlled. > > global-capability-whitelist (controlled_userns_caps_whitelist) is used > at the capability check-time and keeps the semantics for the processes > that belong to uncontrolled user-ns as it is. Processes that belong to > controlled user-ns however are subjected to different checks- > > (a) if the capability in question is controlled and process belongs > to controlled user-ns, then it's always denied. > (b) if the capability in question is NOT controlled then fall back > to the traditional check. > > Signed-off-by: Mahesh Bandewar Acked-by: Serge Hallyn Although a few comment addition requests below: > --- > v2: > Don't recalculate user-ns flags for every setns() call. > v1: > Initial submission. > > include/linux/capability.h | 1 + > include/linux/user_namespace.h | 20 ++++++++++++++++++++ > kernel/capability.c | 5 +++++ > kernel/user_namespace.c | 4 ++++ > security/commoncap.c | 8 ++++++++ > 5 files changed, 38 insertions(+) > > diff --git a/include/linux/capability.h b/include/linux/capability.h > index 7d79a4689625..a1fd9e460379 100644 > --- a/include/linux/capability.h > +++ b/include/linux/capability.h > @@ -251,6 +251,7 @@ extern bool ptracer_capable(struct task_struct *tsk, struct user_namespace *ns); > extern int get_vfs_caps_from_disk(const struct dentry *dentry, struct cpu_vfs_cap_data *cpu_caps); > int proc_douserns_caps_whitelist(struct ctl_table *table, int write, > void __user *buff, size_t *lenp, loff_t *ppos); Here and at the definition below, please add a comment explaining that a controlled cap is defined as not being in the sysctl. > +bool is_capability_controlled(int cap); > > extern int cap_convert_nscap(struct dentry *dentry, void **ivalue, size_t size); > > diff --git a/include/linux/user_namespace.h b/include/linux/user_namespace.h > index 3fe714da7f5a..647f825c7b5f 100644 > --- a/include/linux/user_namespace.h > +++ b/include/linux/user_namespace.h > @@ -23,6 +23,7 @@ struct uid_gid_map { /* 64 bytes -- 1 cache line */ > }; > > #define USERNS_SETGROUPS_ALLOWED 1UL > +#define USERNS_CONTROLLED 2UL > > #define USERNS_INIT_FLAGS USERNS_SETGROUPS_ALLOWED > > @@ -103,6 +104,16 @@ static inline void put_user_ns(struct user_namespace *ns) > __put_user_ns(ns); > } > Please add a comment explaining that a controlled ns is one created by a user which did not have CAP_SYS_ADMIN (or descended from such an ns). > +static inline bool is_user_ns_controlled(const struct user_namespace *ns) > +{ > + return ns->flags & USERNS_CONTROLLED; > +} > + > +static inline void mark_user_ns_controlled(struct user_namespace *ns) > +{ > + ns->flags |= USERNS_CONTROLLED; > +} > + > struct seq_operations; > extern const struct seq_operations proc_uid_seq_operations; > extern const struct seq_operations proc_gid_seq_operations; > @@ -161,6 +172,15 @@ static inline struct ns_common *ns_get_owner(struct ns_common *ns) > { > return ERR_PTR(-EPERM); > } > + > +static inline bool is_user_ns_controlled(const struct user_namespace *ns) > +{ > + return false; > +} > + > +static inline void mark_user_ns_controlled(struct user_namespace *ns) > +{ > +} > #endif > > #endif /* _LINUX_USER_H */ > diff --git a/kernel/capability.c b/kernel/capability.c > index 4a859b7d4902..bffe249922de 100644 > --- a/kernel/capability.c > +++ b/kernel/capability.c > @@ -511,6 +511,11 @@ bool ptracer_capable(struct task_struct *tsk, struct user_namespace *ns) > } > > /* Controlled-userns capabilities routines */ > +bool is_capability_controlled(int cap) > +{ > + return !cap_raised(controlled_userns_caps_whitelist, cap); > +} > + > #ifdef CONFIG_SYSCTL > int proc_douserns_caps_whitelist(struct ctl_table *table, int write, > void __user *buff, size_t *lenp, loff_t *ppos) > diff --git a/kernel/user_namespace.c b/kernel/user_namespace.c > index c490f1e4313b..600c7dcb9ff7 100644 > --- a/kernel/user_namespace.c > +++ b/kernel/user_namespace.c > @@ -139,6 +139,10 @@ int create_user_ns(struct cred *new) > goto fail_keyring; > > set_cred_user_ns(new, ns); > + if (!ns_capable(parent_ns, CAP_SYS_ADMIN) || > + is_user_ns_controlled(parent_ns)) > + mark_user_ns_controlled(ns); > + > return 0; > fail_keyring: > #ifdef CONFIG_PERSISTENT_KEYRINGS > diff --git a/security/commoncap.c b/security/commoncap.c > index fc46f5b85251..89103f16ac37 100644 > --- a/security/commoncap.c > +++ b/security/commoncap.c > @@ -73,6 +73,14 @@ int cap_capable(const struct cred *cred, struct user_namespace *targ_ns, > { > struct user_namespace *ns = targ_ns; > > + /* If the capability is controlled and user-ns that process > + * belongs-to is 'controlled' then return EPERM and no need > + * to check the user-ns hierarchy. > + */ > + if (is_user_ns_controlled(cred->user_ns) && > + is_capability_controlled(cap)) > + return -EPERM; I'd be curious to see the performance impact on this on a regular workload (kernel build?) in a controlled ns. > + > /* See if cred has the capability in the target user namespace > * by examining the target user namespace and all of the target > * user namespace's parents. > -- > 2.15.0.448.gf294e3d99a-goog From 1583656299755400145@xxx Fri Nov 10 05:38:59 +0000 2017 X-GM-THRID: 1583656299755400145 X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread