[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220722082159.jgvw7jgds3qwfyqk@wittgenstein>
Date: Fri, 22 Jul 2022 10:21:59 +0200
From: Christian Brauner <brauner@...nel.org>
To: Frederick Lawler <fred@...udflare.com>
Cc: kpsingh@...nel.org, revest@...omium.org, jackmanb@...omium.org,
ast@...nel.org, daniel@...earbox.net, andrii@...nel.org,
kafai@...com, songliubraving@...com, yhs@...com,
john.fastabend@...il.com, jmorris@...ei.org, serge@...lyn.com,
paul@...l-moore.com, stephen.smalley.work@...il.com,
eparis@...isplace.org, shuah@...nel.org, casey@...aufler-ca.com,
ebiederm@...ssion.com, bpf@...r.kernel.org,
linux-security-module@...r.kernel.org, selinux@...r.kernel.org,
linux-kselftest@...r.kernel.org, linux-kernel@...r.kernel.org,
netdev@...r.kernel.org, kernel-team@...udflare.com,
cgzones@...glemail.com, karl@...badwolfsecurity.com
Subject: Re: [PATCH v3 1/4] security, lsm: Introduce security_create_user_ns()
On Thu, Jul 21, 2022 at 12:28:05PM -0500, Frederick Lawler wrote:
> Preventing user namespace (privileged or otherwise) creation comes in a
> few of forms in order of granularity:
>
> 1. /proc/sys/user/max_user_namespaces sysctl
> 2. OS specific patch(es)
> 3. CONFIG_USER_NS
>
> To block a task based on its attributes, the LSM hook cred_prepare is a
> good candidate for use because it provides more granular control, and
> it is called before create_user_ns():
>
> cred = prepare_creds()
> security_prepare_creds()
> call_int_hook(cred_prepare, ...
> if (cred)
> create_user_ns(cred)
>
> Since security_prepare_creds() is meant for LSMs to copy and prepare
> credentials, access control is an unintended use of the hook. Therefore
> introduce a new function security_create_user_ns() with an accompanying
> userns_create LSM hook.
>
> This hook takes the prepared creds for LSM authors to write policy
> against. On success, the new namespace is applied to credentials,
> otherwise an error is returned.
>
> Signed-off-by: Frederick Lawler <fred@...udflare.com>
>
> ---
Nice and straightforward,
Reviewed-by: Christian Brauner (Microsoft) <brauner@...nel.org>
Powered by blists - more mailing lists