linux-security-module.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Paul Moore <paul@paul-moore.com>
To: Casey Schaufler <casey@schaufler-ca.com>
Cc: casey.schaufler@intel.com, 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
Subject: Re: [PATCH v1 6/8] LSM: lsm_self_attr syscall for LSM self attributes
Date: Wed, 9 Nov 2022 18:34:57 -0500	[thread overview]
Message-ID: <CAHC9VhQ039=X+0edudy64-fpw4C2SwWV_MucbYfXwFKduwnbWA@mail.gmail.com> (raw)
In-Reply-To: <20221025184519.13231-7-casey@schaufler-ca.com>

On Tue, Oct 25, 2022 at 2:48 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>
> Create a system call lsm_self_attr() to provide the security
> module maintained attributes of the current process. Historically
> these attributes have been exposed to user space via entries in
> procfs under /proc/self/attr.
>
> Attributes are provided as a collection of lsm_ctx structures
> which are placed into a user supplied buffer. Each structure
> identifys the security module providing the attribute, which
> of the possible attributes is provided, the size of the
> attribute, and finally the attribute value. The format of the
> attribute value is defined by the security module, but will
> always be \0 terminated. The ctx_len value will be larger than
> strlen(ctx).
>
>         ------------------------------
>         | unsigned int id            |
>         ------------------------------
>         | unsigned int flags         |
>         ------------------------------
>         | __kernel_size_t ctx_len    |
>         ------------------------------
>         | unsigned char ctx[ctx_len] |
>         ------------------------------
>         | unsigned int id            |
>         ------------------------------
>         | unsigned int flags         |
>         ------------------------------
>         | __kernel_size_t ctx_len    |
>         ------------------------------
>         | unsigned char ctx[ctx_len] |
>         ------------------------------
>
> Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
> ---
>  include/linux/syscalls.h |   2 +
>  include/uapi/linux/lsm.h |  21 ++++++
>  kernel/sys_ni.c          |   3 +
>  security/Makefile        |   1 +
>  security/lsm_syscalls.c  | 156 +++++++++++++++++++++++++++++++++++++++
>  5 files changed, 183 insertions(+)
>  create mode 100644 security/lsm_syscalls.c

...

> diff --git a/include/uapi/linux/lsm.h b/include/uapi/linux/lsm.h
> index 61e13b1b9ece..1d27fb5b7746 100644
> --- a/include/uapi/linux/lsm.h
> +++ b/include/uapi/linux/lsm.h
> @@ -9,6 +9,27 @@
>  #ifndef _UAPI_LINUX_LSM_H
>  #define _UAPI_LINUX_LSM_H
>
> +#include <linux/types.h>
> +#include <linux/unistd.h>
> +
> +/**
> + * struct lsm_ctx - LSM context
> + * @id: the LSM id number, see LSM_ID_XXX
> + * @flags: context specifier and LSM specific flags
> + * @ctx_len: the size of @ctx
> + * @ctx: the LSM context, a nul terminated string
> + *
> + * @ctx in a nul terminated string.
> + *     (strlen(@ctx) < @ctx_len) is always true.
> + *     (strlen(@ctx) == @ctx_len + 1) is not guaranteed.
> + */

We can do better than this, or rather we *should* do better than this.
One of the big advantages of creating a new API is we can fix some of
the silly things we have had to do in the past, including the
"sometimes" NUL terminator on strings.  For this LSM syscalls let's
make a promise that all human readable strings will be properly NUL
terminated; currently this includes all LSM contexts, and likely will
remain that way forever for various reasons, but let's leave the door
open for arbitrary blobs (see the "special" LSM ID discussion from
earlier in the patchset).  With that in mind I might suggest the
following:

  /**
   * struct lsm_ctx - LSM context
   * @id: the LSM id number, see LSM_ID_XXX
   * @flags: context specifier and LSM specific flags
   * @ctx_len: the size of @ctx
   * @ctx: the LSM context, see description
   *
   * For LSMs which provide human readable contexts @ctx will be a nul
   * terminated string and @ctx_len will include the size of the string
   * and the nul terminator, e.g. 'ctx_len == strlen(ctx) + 1'.  For LSMs
   * which provide binary-only contexts @cts will be a binary blob with
   * @ctx_len being the exact value of the blob.  The type of the @ctx,
   * human readable string or binary, can be determined by inspecting
   * both @id and @flags.
   *
   * If a given LSM @id does not define a set of values for use in the
   * @flags field, @flags MUST be set to zero.
   */
  struct lsm_ctx {
    __u32 id;
    __U32 flags;
    __kernel_size_t ctx_len;
    __u8 ctx[];
  };

> +struct lsm_ctx {
> +       unsigned int            id;
> +       unsigned int            flags;
> +       __kernel_size_t         ctx_len;
> +       unsigned char           ctx[];
> +};

I agree with Greg, we should be explicit about variable sizing, let's
make sure everything in the UAPI header is defined in terms of
__uXX/__sXX.  This includes strings as __u8 arrays.

Also, I sorta despite the 'let's line all the struct fields up
horizontally!' approach in struct/variable definitions.  I personally
think it looks horrible and it clutters up future patches.  Please
don't do this unless the individual file already does it, and since we
are creating this new please don't :)

> diff --git a/security/lsm_syscalls.c b/security/lsm_syscalls.c
> new file mode 100644
> index 000000000000..da0fab7065e2
> --- /dev/null
> +++ b/security/lsm_syscalls.c
> @@ -0,0 +1,156 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * System calls implementing the Linux Security Module API.
> + *
> + *  Copyright (C) 2022 Casey Schaufler <casey@schaufler-ca.com>
> + *  Copyright (C) Intel Corporation
> + */
> +
> +#include <asm/current.h>
> +#include <linux/compiler_types.h>
> +#include <linux/err.h>
> +#include <linux/errno.h>
> +#include <linux/security.h>
> +#include <linux/stddef.h>
> +#include <linux/syscalls.h>
> +#include <linux/types.h>
> +#include <linux/lsm_hooks.h>
> +#include <uapi/linux/lsm.h>
> +
> +struct feature_map {
> +       char *name;
> +       int feature;
> +};
> +
> +static const struct feature_map lsm_attr_names[] = {
> +       { .name = "current",    .feature = LSM_ATTR_CURRENT, },
> +       { .name = "exec",       .feature = LSM_ATTR_EXEC, },
> +       { .name = "fscreate",   .feature = LSM_ATTR_FSCREATE, },
> +       { .name = "keycreate",  .feature = LSM_ATTR_KEYCREATE, },
> +       { .name = "prev",       .feature = LSM_ATTR_PREV, },
> +       { .name = "sockcreate", .feature = LSM_ATTR_SOCKCREATE, },
> +};
> +
> +/**
> + * lsm_self_attr - Return current task's security module attributes
> + * @ctx: the LSM contexts
> + * @size: size of @ctx, updated on return
> + * @flags: reserved for future use, must be zero
> + *
> + * Returns the calling task's LSM contexts. On success this
> + * function returns the number of @ctx array elements. This value
> + * may be zero if there are no LSM contexts assigned. If @size is
> + * insufficient to contain the return data -E2BIG is returned and
> + * @size is set to the minimum required size. In all other cases
> + * a negative value indicating the error is returned.
> + */
> +SYSCALL_DEFINE3(lsm_self_attr,
> +              struct lsm_ctx __user *, ctx,
> +              size_t __user *, size,
> +              int, flags)

See my comments above about UAPI types, let's change this to something
like this:

[NOTE: I'm assuming it is safe to use __XXX types in syscall declarations?]

  SYSCALL_DEFINE3(lsm_self_attr,
                 struct lsm_ctx __user *, ctx,
                 __kernel_size_t __user *, size,
                 __u32, flags)

> +{
> +       struct lsm_ctx *final = NULL;
> +       struct lsm_ctx *interum;
> +       struct lsm_ctx *ip;
> +       void *curr;
> +       char **interum_ctx;
> +       char *cp;
> +       size_t total_size = 0;
> +       int count = 0;
> +       int attr;
> +       int len;
> +       int rc = 0;
> +       int i;

Ungh, reverse christmas trees ... I kinda hate it from a style
perspective, enough to mention it here, but I'm not going to be petty
enough to say "change it".

However, if you did want to flip it upside down (normal christmas
tree?) during the respin I would be grateful ;)

--
paul-moore.com

  parent reply	other threads:[~2022-11-09 23:35 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20221025184519.13231-1-casey.ref@schaufler-ca.com>
2022-10-25 18:45 ` [PATCH v1 0/8] LSM: Two basic syscalls Casey Schaufler
2022-10-25 18:45   ` [PATCH v1 1/8] LSM: Identify modules by more than name Casey Schaufler
2022-10-26  5:56     ` Greg KH
2022-10-25 18:45   ` [PATCH v1 2/8] LSM: Add an LSM identifier for external use Casey Schaufler
2022-10-26  5:58     ` Greg KH
2022-10-26 19:36       ` Casey Schaufler
2022-10-27  0:11         ` Tetsuo Handa
2022-10-27  6:31         ` Greg KH
2022-10-28 16:54           ` Casey Schaufler
2022-11-09 23:33             ` Paul Moore
2022-11-10  0:57               ` Casey Schaufler
2022-11-10  2:37                 ` Paul Moore
2022-11-09 23:33     ` Paul Moore
2022-11-10  0:46       ` Casey Schaufler
2022-10-25 18:45   ` [PATCH v1 3/8] LSM: Identify the process attributes for each module Casey Schaufler
2022-10-26  5:59     ` Greg KH
2022-11-09 23:34     ` Paul Moore
2022-11-10  1:03       ` Casey Schaufler
2022-11-10  2:39         ` Paul Moore
2022-10-25 18:45   ` [PATCH v1 4/8] LSM: Maintain a table of LSM attribute data Casey Schaufler
2022-10-26  6:00     ` Greg KH
2022-10-27  0:38       ` Casey Schaufler
2022-10-27  6:29         ` Greg KH
2022-10-27 17:08           ` Casey Schaufler
2022-10-27 17:13             ` Greg KH
2022-11-09 23:34               ` Paul Moore
2022-10-25 18:45   ` [PATCH v1 5/8] proc: Use lsmids instead of lsm names for attrs Casey Schaufler
2022-10-25 18:45   ` [PATCH v1 6/8] LSM: lsm_self_attr syscall for LSM self attributes Casey Schaufler
2022-10-26  6:03     ` Greg KH
2022-10-26  7:01     ` kernel test robot
2022-10-26  8:14     ` kernel test robot
2022-10-26  9:33     ` kernel test robot
2022-11-09 23:34     ` Paul Moore [this message]
2022-11-10  1:32       ` Casey Schaufler
2022-11-10  3:02         ` Paul Moore
2022-11-10 23:36       ` Paul Moore
2022-11-11  0:36         ` Casey Schaufler
2022-11-11  3:16           ` Paul Moore
2022-10-25 18:45   ` [PATCH v1 7/8] LSM: Create lsm_module_list system call Casey Schaufler
2022-10-26  6:02     ` Greg KH
2022-10-26 12:07     ` kernel test robot
2022-11-09 23:35     ` Paul Moore
2022-11-10  1:37       ` Casey Schaufler
2022-11-10  3:17         ` Paul Moore
2022-10-25 18:45   ` [PATCH v1 8/8] lsm: wireup syscalls lsm_self_attr and lsm_module_list Casey Schaufler
2022-10-26  8:07     ` Geert Uytterhoeven
2022-11-23 19:57 [PATCH v1 0/8] LSM: Two basic syscalls Casey Schaufler
2022-11-23 19:57 ` [PATCH v1 6/8] LSM: lsm_self_attr syscall for LSM self attributes Casey Schaufler

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='CAHC9VhQ039=X+0edudy64-fpw4C2SwWV_MucbYfXwFKduwnbWA@mail.gmail.com' \
    --to=paul@paul-moore.com \
    --cc=casey.schaufler@intel.com \
    --cc=casey@schaufler-ca.com \
    --cc=jmorris@namei.org \
    --cc=john.johansen@canonical.com \
    --cc=keescook@chromium.org \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=mic@digikod.net \
    --cc=penguin-kernel@i-love.sakura.ne.jp \
    --cc=stephen.smalley.work@gmail.com \
    /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).