On 10/5/2023 5:58 AM, Tetsuo Handa wrote: > 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? 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.