On 2023/09/13 5:56, Casey Schaufler wrote:
> 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?
