Received: by 10.223.164.202 with SMTP id h10csp944199wrb; Thu, 9 Nov 2017 17:51:14 -0800 (PST) X-Google-Smtp-Source: ABhQp+SAwpHVjMdHmuu0sBu+KKqnCKEAV80IhBv9cwCIAlKat2BdbA+6FpetWw7rMVQw4peG5LpL X-Received: by 10.99.95.203 with SMTP id t194mr2350795pgb.318.1510278674583; Thu, 09 Nov 2017 17:51:14 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1510278674; cv=none; d=google.com; s=arc-20160816; b=GdUJgJdW5+gZ1u5MMO1MUTIAGixJv2B1XeBBWcGuLETtJHqd5p7ZRwVgH07G9kYDXg KA2qAsQG636BAmpthcFrU4SzaUsNxuDZTIvISWqk7qCHu5bWEu+cggCxSAu8FVOARuQ5 UmMZWMjbRr5lYe+zUd/j91rr5rNtghLOYV1sUAZQYXr6a8FbgYtzjmqLTV8SKpItB6Za bQSDsECrjguSKMlJoZbuqSLR2fLSfvKUmVOXA6zydJNNZUH2sjhGwIyBnoYFk6yp6WJI rhmAhpzWA0CV1+BKDWUB1VwAv7Y27x94OMROw3behe0z1Bfawu26H+Swngrb0oTnrH5v ReoA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=XV3lrLGoYKO1ousXXmi7D+RAyw81x/WvV7YJP0f6fLM=; b=bSJmNBOdfvhshjC+Alou6DZCZwQPCY4b8k0FJNJnQkgr83xWNj45wnoQZF6pp9Ksu2 cL/OLuilh/aLSAVq5+ZKq03hJdRv+dkqJR1iyhl66zRGk0C9iSAYzd+4B+GRm++p8n6s yu0swhF2kt/T1GJa5YFO6JbQkIQ1Hhs6FPdifMq5UHPF4VTc8bU7/cMHZxQTGUbGJi0M /Ih3qMufVfrlPihP+UquBrgjnXnM9q0rB93i0xwUqZLxN6xcn8ARAjC1l88h6ngrvhLu /KzrofwzIvCK4UoakeyvYjdwELCejHUpZDAWNMNTxzaceRoOs49idKq4b34oCHgJ38HQ OetQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=KL2iSEyb; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m1si7594512pls.217.2017.11.09.17.51.02; Thu, 09 Nov 2017 17:51:14 -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; dkim=pass header.i=@google.com header.s=20161025 header.b=KL2iSEyb; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755623AbdKJBuX (ORCPT + 83 others); Thu, 9 Nov 2017 20:50:23 -0500 Received: from mail-yw0-f196.google.com ([209.85.161.196]:51171 "EHLO mail-yw0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755527AbdKJBuU (ORCPT ); Thu, 9 Nov 2017 20:50:20 -0500 Received: by mail-yw0-f196.google.com with SMTP id i198so6986541ywe.7 for ; Thu, 09 Nov 2017 17:50:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=XV3lrLGoYKO1ousXXmi7D+RAyw81x/WvV7YJP0f6fLM=; b=KL2iSEybJjSl0XYj3josWeR8+5c8m+6Auif2lh5p1gedSA9Y+56iiVQNIY4EBJKwwK ngRwSwaShnekxwVcSdgQlPOSR6/ZoeYzXmM8yfFJspAJRKOtLUvyEnIgccn42D2Q4w7M eS6NtCtwYWr40f19+k3YDlobNAFxA5o0+xT4n2LWVDZLcy0jQJ/kX7tGLzF7+9XHg/Ms c6+DJtXQ/TO2Z+V6ro0vaDiy5jkctt7FkC3YiTs79D3ogtpanygonNDBMlBGy6b3lxUU MBIgY8BsHsxYu2h8p8uDlHTVMyBfVKhwjVH1A90agZbHGEhci2oBCnOEevryP4fDFq6N 7Vag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=XV3lrLGoYKO1ousXXmi7D+RAyw81x/WvV7YJP0f6fLM=; b=uLOs+oBD0FOPP52j919XMaAUHiYqR4Q5dupfw2xJvyfIWu5MW5es8GG3w766tiuXxm Rpd0OQxIDJCu1jkKjbqqTBS+RYc50PcDTPcIQYxmZ5BhLRtbcSFJ00ORdg/olBFBYNQD fs/9rZCjyRTNTxxCVY1JCnHwvz2WpQ/LEhBltmCpS2dm8du4pTOiAq4htsmDU19ub5bV hwfCNbt/+s8EICyX+zoVWJURLRPy4yOhsMc734yLJ4OUD9rCyzS3cmbrMBsYaNw7naH1 7qP/2f/amYqP3Or0HpCPZBdRMToj2jKnkuczFInbFm2ok1VuE6rV3r7CnuP/sDrauqK3 ynLQ== X-Gm-Message-State: AJaThX4H5G9a74cxJcC8RCNLlz2hDOQZM66eQp/C+YdKENt08gpbU/GZ 6RWvPrmuQ8klppp+ZDyElWhXcEwnjl/F/Y92vYe1AQ== X-Received: by 10.37.7.3 with SMTP id 3mr1716942ybh.376.1510278619377; Thu, 09 Nov 2017 17:50:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.131.198 with HTTP; Thu, 9 Nov 2017 17:49:58 -0800 (PST) In-Reply-To: <20171109172544.GB26229@mail.hallyn.com> References: <20171103004436.40026-1-mahesh@bandewar.net> <20171109172544.GB26229@mail.hallyn.com> From: =?UTF-8?B?TWFoZXNoIEJhbmRld2FyICjgpK7gpLngpYfgpLYg4KSs4KSC4KSh4KWH4KS14KS+4KSwKQ==?= Date: Fri, 10 Nov 2017 10:49:58 +0900 Message-ID: Subject: Re: [PATCH resend 2/2] userns: control capabilities of some user namespaces To: "Serge E. Hallyn" Cc: Mahesh Bandewar , LKML , Netdev , Kernel-hardening , Linux API , Kees Cook , "Eric W . Biederman" , Eric Dumazet , David Miller Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Nov 10, 2017 at 2:25 AM, Serge E. Hallyn wrote: > 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 >> --- >> include/linux/capability.h | 1 + >> include/linux/user_namespace.h | 20 ++++++++++++++++++++ >> kernel/capability.c | 5 +++++ >> kernel/user_namespace.c | 3 +++ >> security/commoncap.c | 8 ++++++++ >> 5 files changed, 37 insertions(+) >> >> diff --git a/include/linux/capability.h b/include/linux/capability.h >> index 6c0b9677c03f..b8c6cac18658 100644 >> --- a/include/linux/capability.h >> +++ b/include/linux/capability.h >> @@ -250,6 +250,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); >> +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 c18e01252346..e890fe81b47e 100644 >> --- a/include/linux/user_namespace.h >> +++ b/include/linux/user_namespace.h >> @@ -22,6 +22,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 >> >> @@ -102,6 +103,16 @@ static inline void put_user_ns(struct user_namespace *ns) >> __put_user_ns(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; >> @@ -160,6 +171,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 62dbe3350c1b..40a38cc4ff43 100644 >> --- a/kernel/capability.c >> +++ b/kernel/capability.c >> @@ -510,6 +510,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..f393ea5108f0 100644 >> --- a/kernel/user_namespace.c >> +++ b/kernel/user_namespace.c >> @@ -53,6 +53,9 @@ static void set_cred_user_ns(struct cred *cred, struct user_namespace *user_ns) >> cred->cap_effective = CAP_FULL_SET; >> cred->cap_ambient = CAP_EMPTY_SET; >> cred->cap_bset = CAP_FULL_SET; >> + if (!ns_capable(user_ns->parent, CAP_SYS_ADMIN) || >> + is_user_ns_controlled(user_ns->parent)) >> + mark_user_ns_controlled(user_ns); > > Hm, why do this here, rather than at create_user_ns()? It > shouldn't be recalculated when someone does setns() should it? > You are absolutely right! It doesn't make sense to recalculate for every setns() call. It's a side effect of couple of iterations / approaches that I tried before finalizing this one. I'll move this block to create_user_ns() after the set_cred_user_ns() call so that this wont be triggered in setns() path. Thanks, --mahesh.. From 1583627421134988911@xxx Thu Nov 09 21:59:58 +0000 2017 X-GM-THRID: 1583003759650790753 X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread