From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 73352C74A5B for ; Thu, 30 Mar 2023 01:13:39 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229501AbjC3BNi (ORCPT ); Wed, 29 Mar 2023 21:13:38 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41858 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229603AbjC3BNh (ORCPT ); Wed, 29 Mar 2023 21:13:37 -0400 Received: from mail-yb1-xb32.google.com (mail-yb1-xb32.google.com [IPv6:2607:f8b0:4864:20::b32]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9CE9D10F3 for ; Wed, 29 Mar 2023 18:13:36 -0700 (PDT) Received: by mail-yb1-xb32.google.com with SMTP id f188so3244125ybb.3 for ; Wed, 29 Mar 2023 18:13:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paul-moore.com; s=google; t=1680138816; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=mD7V827LGMQPDZbYWYTAu0xqEkrvaQm+VNiFn3rB9QQ=; b=EBrqm2rDlSB6FuiS8DTfp+/vWKwVt9hpV0zhN0JAOunLZZhcROqVbb0JQ0AaMUKqyT a4lV2L7GWtZwYSMcj9RkdeqD5UAu7Tg4SCPLsl9FOsecFPLjxbms6VjuN+PIraWEkCSo I1NLYy1TeIH8x2jsAnxo2e6to9SXQev011GxU2WqzyHpXaTgr1vEcYBHdSNXsdawOtOS 6q9Y6OORsj+i3XlaMcLeGh00oPW1nRuHGrOUpDhGBMn9VsBXN53AExx62294YnB4sT0k AjOj8DA3wwqLLLdelTif+Em6PND78Xgooyq0dCFhFK5/Ux1B3vEFUyNdvfw73s6OvXFT ZN2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680138816; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=mD7V827LGMQPDZbYWYTAu0xqEkrvaQm+VNiFn3rB9QQ=; b=ifmtZ3khxA3inZfIgPMobHG2dM0tVqdnlwTPhUeWSf7DklMHHCjrhgK4qP9HyRNY54 /FwdnTKkxTuuBU0FzO2miN8dMVVqTdZ22SAN8xnk6uga3Oync/abP4gR3ikzBgLOII62 nQVpeH/ZyTb7043RC+sRw80NaOk0bu2Mo3qJUHdFP1Qg2c6chrxEAHXb/T0pkVlzXl0+ ZYO7Osf33jp2wpZARM3vOrLes1ZdwozhJeKqDuM7PWGgyW+bd6XkSqvgfF4hPTzCb19S YYqP1aapSqGz9fYfAk3/i4sOrccI/YnR5xL6uNYrn3mW7gnWjDxMrsEZ8fuK+A2LfkLH ogiw== X-Gm-Message-State: AAQBX9eJ62UNPqVrs72qw7KBO8/DtxkqK5TmLNdO5B9uYDXQQfkTUYSl heq2OSqTPaljxtYg7VKuXxRkxD8HxF3mNBh3v1C3 X-Google-Smtp-Source: AKy350aLjsjvpAwhol6hTTKWeSJXqiTRC6amNQl3l2YyGTmzC92tDsow1wYnpDLkuu/ZTZRpeh+bHilakoLHCD8u+eY= X-Received: by 2002:a05:6902:70a:b0:b6e:361a:c86 with SMTP id k10-20020a056902070a00b00b6e361a0c86mr11608972ybt.3.1680138816161; Wed, 29 Mar 2023 18:13:36 -0700 (PDT) MIME-Version: 1.0 References: <20230315224704.2672-1-casey@schaufler-ca.com> <20230315224704.2672-8-casey@schaufler-ca.com> In-Reply-To: <20230315224704.2672-8-casey@schaufler-ca.com> From: Paul Moore Date: Wed, 29 Mar 2023 21:13:25 -0400 Message-ID: Subject: Re: [PATCH v7 07/11] LSM: Helpers for attribute names and filling an lsm_ctx To: Casey Schaufler Cc: linux-security-module@vger.kernel.org, jmorris@namei.org, keescook@chromium.org, john.johansen@canonical.com, penguin-kernel@i-love.sakura.ne.jp, stephen.smalley.work@gmail.com, linux-kernel@vger.kernel.org, linux-api@vger.kernel.org, mic@digikod.net Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: On Wed, Mar 15, 2023 at 6:50=E2=80=AFPM Casey Schaufler wrote: > > Add lsm_name_to_attr(), which translates a text string to a > LSM_ATTR value if one is available. > > Add lsm_fill_user_ctx(), which fills a struct lsm_ctx, including > the trailing attribute value. > > All are used in module specific components of LSM system calls. > > Signed-off-by: Casey Schaufler > --- > include/linux/security.h | 13 ++++++++++ > security/lsm_syscalls.c | 51 ++++++++++++++++++++++++++++++++++++++++ > security/security.c | 31 ++++++++++++++++++++++++ > 3 files changed, 95 insertions(+) ... > diff --git a/security/lsm_syscalls.c b/security/lsm_syscalls.c > index 6efbe244d304..55d849ad5d6e 100644 > --- a/security/lsm_syscalls.c > +++ b/security/lsm_syscalls.c > @@ -17,6 +17,57 @@ > #include > #include > > +struct attr_map { > + char *name; > + u64 attr; > +}; > + > +static const struct attr_map lsm_attr_names[] =3D { > + { > + .name =3D "current", > + .attr =3D LSM_ATTR_CURRENT, > + }, > + { > + .name =3D "exec", > + .attr =3D LSM_ATTR_EXEC, > + }, > + { > + .name =3D "fscreate", > + .attr =3D LSM_ATTR_FSCREATE, > + }, > + { > + .name =3D "keycreate", > + .attr =3D LSM_ATTR_KEYCREATE, > + }, > + { > + .name =3D "prev", > + .attr =3D LSM_ATTR_PREV, > + }, > + { > + .name =3D "sockcreate", > + .attr =3D LSM_ATTR_SOCKCREATE, > + }, > +}; > + > +/** > + * lsm_name_to_attr - map an LSM attribute name to its ID > + * @name: name of the attribute > + * > + * Look the given @name up in the table of know attribute names. > + * > + * Returns the LSM attribute value associated with @name, or 0 if > + * there is no mapping. > + */ > +u64 lsm_name_to_attr(const char *name) > +{ > + int i; > + > + for (i =3D 0; i < ARRAY_SIZE(lsm_attr_names); i++) > + if (!strcmp(name, lsm_attr_names[i].name)) > + return lsm_attr_names[i].attr; I'm pretty sure this is the only place where @lsm_attr_names is used, right? If true, when coupled with the idea that these syscalls are going to close the door on new LSM attributes in procfs I think we can just put the mapping directly in this function via a series of if-statements. > + return 0; > +} > + > /** > * sys_lsm_set_self_attr - Set current task's security module attribute > * @attr: which attribute to set > diff --git a/security/security.c b/security/security.c > index 2c57fe28c4f7..f7b814a3940c 100644 > --- a/security/security.c > +++ b/security/security.c > @@ -753,6 +753,37 @@ static int lsm_superblock_alloc(struct super_block *= sb) > return 0; > } > > +/** > + * lsm_fill_user_ctx - Fill a user space lsm_ctx structure > + * @ctx: an LSM context to be filled > + * @context: the new context value > + * @context_size: the size of the new context value > + * @id: LSM id > + * @flags: LSM defined flags > + * > + * Fill all of the fields in a user space lsm_ctx structure. > + * Caller is assumed to have verified that @ctx has enough space > + * for @context. > + * Returns 0 on success, -EFAULT on a copyout error. > + */ > +int lsm_fill_user_ctx(struct lsm_ctx __user *ctx, void *context, > + size_t context_size, u64 id, u64 flags) > +{ > + struct lsm_ctx local; > + void __user *vc =3D ctx; > + > + local.id =3D id; > + local.flags =3D flags; > + local.ctx_len =3D context_size; > + local.len =3D context_size + sizeof(local); > + vc +=3D sizeof(local); See my prior comments about void pointer math. > + if (copy_to_user(ctx, &local, sizeof(local))) > + return -EFAULT; > + if (context_size > 0 && copy_to_user(vc, context, context_size)) > + return -EFAULT; Should we handle the padding in this function? > + return 0; > +} -- paul-moore.com