From: "Serge E. Hallyn" <serge@hallyn.com>
To: Mahesh Bandewar <mahesh@bandewar.net>
Cc: LKML <linux-kernel@vger.kernel.org>,
Netdev <netdev@vger.kernel.org>,
Kernel-hardening <kernel-hardening@lists.openwall.com>,
Linux API <linux-api@vger.kernel.org>,
Kees Cook <keescook@chromium.org>,
Serge Hallyn <serge@hallyn.com>,
"Eric W . Biederman" <ebiederm@xmission.com>,
Eric Dumazet <edumazet@google.com>,
David Miller <davem@davemloft.net>,
Mahesh Bandewar <maheshb@google.com>
Subject: Re: [PATCH resend 2/2] userns: control capabilities of some user namespaces
Date: Thu, 9 Nov 2017 11:25:44 -0600 [thread overview]
Message-ID: <20171109172544.GB26229@mail.hallyn.com> (raw)
In-Reply-To: <20171103004436.40026-1-mahesh@bandewar.net>
Quoting Mahesh Bandewar (mahesh@bandewar.net):
> From: Mahesh Bandewar <maheshb@google.com>
>
> 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 <maheshb@google.com>
> ---
> 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?
next prev parent reply other threads:[~2017-11-09 17:25 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-03 0:44 [PATCH resend 2/2] userns: control capabilities of some user namespaces Mahesh Bandewar
[not found] ` <20171103004436.40026-1-mahesh-bmGAjcP2qsnk1uMJSBkQmQ@public.gmane.org>
2017-11-04 23:53 ` Serge E. Hallyn
[not found] ` <20171104235346.GA17170-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>
2017-11-06 7:23 ` Mahesh Bandewar (महेश बंडेवार)
2017-11-06 15:03 ` Serge E. Hallyn
[not found] ` <20171106150302.GA26634-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>
2017-11-06 21:33 ` [kernel-hardening] " Daniel Micay
[not found] ` <1510003994.736.0.camel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2017-11-06 22:14 ` Serge E. Hallyn
[not found] ` <20171106221418.GA32543-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>
2017-11-06 22:42 ` Christian Brauner
2017-11-07 2:16 ` Daniel Micay
[not found] ` <1510020963.736.42.camel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2017-11-07 3:23 ` Serge E. Hallyn
2017-11-09 18:01 ` chris hyser
[not found] ` <da764cbf-7522-06a0-6c21-adfa3eaac9c2-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
2017-11-09 18:05 ` Serge E. Hallyn
2017-11-09 18:27 ` chris hyser
2017-11-06 23:17 ` Boris Lukashev
2017-11-06 23:39 ` Serge E. Hallyn
2017-11-07 0:01 ` Boris Lukashev
[not found] ` <CAFUG7CcW077LHcQEqk7qy7iVvmi-3J8psD1Kwj45XvHThiZC6w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-11-07 3:28 ` [kernel-hardening] " Serge E. Hallyn
[not found] ` <20171107032802.GA6669-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>
2017-11-08 11:09 ` Mahesh Bandewar (महेश बंडेवार)
2017-11-08 19:02 ` Christian Brauner
[not found] ` <20171108190223.vdkyepcaegmub6le-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2017-11-09 0:55 ` Mahesh Bandewar (महेश बंडेवार)
[not found] ` <CAF2d9jjed4Q7QvCD9Kpaa7L-Ngg3XFbJvt0jNVUUwt=52wDjjw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-11-09 3:21 ` Serge E. Hallyn
2017-11-09 7:13 ` Mahesh Bandewar (महेश बंडेवार)
2017-11-09 7:18 ` Mahesh Bandewar (महेश बंडेवार)
2017-11-09 16:14 ` Serge E. Hallyn
[not found] ` <CAF2d9jgs5MYn1dMT2mbhF=6UB2Hoo5kwmJhXuE6memBfWzkWXQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-11-09 21:58 ` [kernel-hardening] " Eric W. Biederman
[not found] ` <871sl7dsh8.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2017-11-10 4:30 ` Mahesh Bandewar (महेश बंडेवार)
2017-11-10 4:46 ` Serge E. Hallyn
[not found] ` <20171110044645.GA3694-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>
2017-11-10 5:28 ` Mahesh Bandewar (महेश बंडेवार)
2017-11-09 17:25 ` Serge E. Hallyn [this message]
2017-11-10 1:49 ` Mahesh Bandewar (महेश बंडेवार)
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=20171109172544.GB26229@mail.hallyn.com \
--to=serge@hallyn.com \
--cc=davem@davemloft.net \
--cc=ebiederm@xmission.com \
--cc=edumazet@google.com \
--cc=keescook@chromium.org \
--cc=kernel-hardening@lists.openwall.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mahesh@bandewar.net \
--cc=maheshb@google.com \
--cc=netdev@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).