lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Sat, 23 Sep 2023 13:46:35 +0900
From:   Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
To:     Kees Cook <keescook@...omium.org>
Cc:     Casey Schaufler <casey@...aufler-ca.com>, paul@...l-moore.com,
        linux-security-module@...r.kernel.org, jmorris@...ei.org,
        serge@...lyn.com, john.johansen@...onical.com,
        stephen.smalley.work@...il.com, linux-kernel@...r.kernel.org,
        linux-api@...r.kernel.org, mic@...ikod.net,
        Dave Chinner <david@...morbit.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Jonathan Corbet <corbet@....net>
Subject: Re: [PATCH v15 01/11] LSM: Identify modules by more than name

On 2023/09/21 0:08, Kees Cook wrote:
> I feel like you are willfully not listening to us when we say that this
> doesn't block out of tree LSMs. Again, there is nothing here that stops
> it. To prove this point, here is an out of tree LSM that works with this
> series. So let's move from theoretical to practical: given this example,
> why do you think out of tree LSMs are blocked?

Because an LSM ID value

> diff --git a/include/uapi/linux/lsm.h b/include/uapi/linux/lsm.h
> index eeda59a77c02..23b7a8f79cef 100644
> --- a/include/uapi/linux/lsm.h
> +++ b/include/uapi/linux/lsm.h
> @@ -63,6 +63,8 @@ struct lsm_ctx {
>  #define LSM_ID_BPF		110
>  #define LSM_ID_LANDLOCK		111
>  
> +#define LSM_ID_GOAT		1138
> +
>  /*
>   * LSM_ATTR_XXX definitions identify different LSM attributes
>   * which are used in the kernel's LSM userspace API. Support

is assigned to LSM only when that LSM became no longer out of tree.

I'm against the policy that only LSM modules that succeeded to become
in-tree are assigned LSM ID. That's not a good usage of identifier.

Quoting from https://lkml.kernel.org/r/4a6b6e2c-9872-4d4c-e42e-4ff0fb79f3ae@I-love.SAKURA.ne.jp :

  The sane and the better usage of LSM ID is to register any publicly available
  LSMs. If LSM ID serves as an index for what LSMs are available in the world,
  by maintaining "the LSM module name, the LSM ID value, short description about
  that LSM module, the public git repository or web site for more information
  about that LSM module" pairs, people can easily find what LSMs could be used
  for their purpose, and developers can avoid re-inventing similar LSM modules
  which are already available somewhere in the world (and optionally helps
  avoiding module name collisions with any publicly available LSMs).

You must not say "We don't care about out of tree LSMs." when talking about this patch.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ