On 10/5/2023 5:58 AM, Tetsuo Handa wrote:

On 2023/09/13 5:56, Casey Schaufler wrote:

quoted

Create a struct lsm_id to contain identifying information about Linux
Security Modules (LSMs). At inception this contains the name of the
module and an identifier associated with the security module.  Change
the security_add_hooks() interface to use this structure.  Change the
individual modules to maintain their own struct lsm_id and pass it to
security_add_hooks().

I came to worry about what purpose does the LSM ID value (or more precisely,
"struct lsm_id") is used for. If the LSM ID value is used for only switch
{reading,writing} /proc/self/attr/ of specific LSM module's information, only
LSM modules that use /proc/self/attr/ will need the LSM ID value.

But this series uses "struct lsm_id" as one of arguments for security_add_hooks(),
and might be reused for different purposes.

Then, BPF-based LSMs (which are not considered as in-tree LSM modules, for
only BPF hook is considered as in-tree LSM module) might receive unfavorable
treatment than non BPF-based LSMs? 

[PATCH v15 05/11] says

  Create a system call to report the list of Linux Security Modules
  that are active on the system. The list is provided as an array
  of LSM ID numbers.
  
  The calling application can use this list determine what LSM
  specific actions it might take. That might include choosing an
  output format, determining required privilege or bypassing
  security module specific behavior.

but, at least, name of BPF-based LSMs won't be shown up in lsm_list_modules()
compared to non BPF-based LSMs? Then, the calling application can't use this
list determine what BPF-based LSM specific actions it might take?

That is correct. Just as knowing that your system is using SELinux won't
tell you whether a specific action might be permitted because that's driven
by the loaded policy, so too knowing that your system is using BPF won't
tell you whether a specific action might be permitted because that's driven
by the eBPF programs in place.

I wish we could stop people from saying "BPF-based LSM". BPF is the LSM. The
eBPF programs that implement a "policy" are NOT a LSM. There needs to be a
name for that, but LSM  is  not  it.