Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20220707223228.1940249-1-fred@cloudflare.com> <20220707223228.1940249-5-fred@cloudflare.com>
In-Reply-To: <20220707223228.1940249-5-fred@cloudflare.com>
From:   Paul Moore <paul@paul-moore.com>
Date:   Tue, 19 Jul 2022 21:32:15 -0400
Message-ID: <CAHC9VhTkvPvqGQjyEKbi2pkKBtRQE=Uat34aoKsxjWU0qkF6CA@mail.gmail.com>
Subject: Re: [PATCH v2 4/4] selinux: Implement create_user_ns hook
To:     Frederick Lawler <fred@cloudflare.com>
Cc:     kpsingh@kernel.org, revest@chromium.org, jackmanb@chromium.org,
        ast@kernel.org, daniel@iogearbox.net, andrii@kernel.org,
        kafai@fb.com, songliubraving@fb.com, yhs@fb.com,
        john.fastabend@gmail.com, jmorris@namei.org, serge@hallyn.com,
        stephen.smalley.work@gmail.com, eparis@parisplace.org,
        shuah@kernel.org, brauner@kernel.org, casey@schaufler-ca.com,
        ebiederm@xmission.com, bpf@vger.kernel.org,
        linux-security-module@vger.kernel.org, selinux@vger.kernel.org,
        linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org,
        netdev@vger.kernel.org, kernel-team@cloudflare.com
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Thu, Jul 7, 2022 at 6:32 PM Frederick Lawler <fred@cloudflare.com> wrote:
>
> Unprivileged user namespace creation is an intended feature to enable
> sandboxing, however this feature is often used to as an initial step to
> perform a privilege escalation attack.
>
> This patch implements a new namespace { userns_create } access control
> permission to restrict which domains allow or deny user namespace
> creation. This is necessary for system administrators to quickly protect
> their systems while waiting for vulnerability patches to be applied.
>
> This permission can be used in the following way:
>
>         allow domA_t domB_t : namespace { userns_create };
>
> Signed-off-by: Frederick Lawler <fred@cloudflare.com>
>
> ---
> Changes since v1:
> - Introduce this patch
> ---
>  security/selinux/hooks.c            | 9 +++++++++
>  security/selinux/include/classmap.h | 2 ++
>  2 files changed, 11 insertions(+)
>
> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
> index beceb89f68d9..73fbcb434fe0 100644
> --- a/security/selinux/hooks.c
> +++ b/security/selinux/hooks.c
> @@ -4227,6 +4227,14 @@ static void selinux_task_to_inode(struct task_struct *p,
>         spin_unlock(&isec->lock);
>  }
>
> +static int selinux_userns_create(const struct cred *cred)
> +{
> +       u32 sid = current_sid();
> +
> +       return avc_has_perm(&selinux_state, sid, sid, SECCLASS_NAMESPACE,
> +                                               NAMESPACE__USERNS_CREATE, NULL);
> +}

As we continue to discuss this, I'm beginning to think that having a
dedicated object class for the userns might be a good idea.  I believe
I was the one who gave you these code snippets, so feel free to blame
me for the respin ;)

This is what I'm thinking:

  static int selinux_userns_create(const struct cred *cred)
  {
    u32 sid = current_sid();

    return avc_has_perm(&selinux_state, sid, sid,
                        SECCLASS_USER_NAMESPACE,
                        USER_NAMESPACE__CREATE, NULL);
  }

> diff --git a/security/selinux/include/classmap.h b/security/selinux/include/classmap.h
> index ff757ae5f253..9943e85c6b3e 100644
> --- a/security/selinux/include/classmap.h
> +++ b/security/selinux/include/classmap.h
> @@ -254,6 +254,8 @@ const struct security_class_mapping secclass_map[] = {
>           { COMMON_FILE_PERMS, NULL } },
>         { "io_uring",
>           { "override_creds", "sqpoll", NULL } },
> +       { "namespace",
> +         { "userns_create", NULL } },

The above would need to change to:

  { "user_namespace",
    { "create", NULL } }

-- 
paul-moore.com