On 2023/10/02 19:56, Tetsuo Handa wrote: >> This is exactly the solution I have been contemplating since this >> discussion began. It will address the bulk of the issue. I'm almost >> mad/crazy enough to produce the patch to demonstrate it. Almost. > > Yes, please show us one. If "[PATCH v15 01/11] LSM: Identify modules by more than name" does not allow LKM-based LSMs (which are likely out-of-tree) to have stable LSM ID values, lsm_list_modules() provided by "[PATCH v15 05/11] LSM: Create lsm_list_modules system call" cannot report stable string names. And "[PATCH v15 11/11] LSM: selftests for Linux Security Module syscalls" cannot work on LKM-based LSMs. Then, how are LKM-based LSMs activated? LKM-based LSMs can use LSM hooks but cannot use (or show up in) lsm_get_self_attr()/lsm_set_self_attr()/lsm_list_modules() syscalls? That looks quite strange, for the title of "[PATCH v15 01/11]" is not "LSM: Identify only built-in and in-tree modules by more than name". If you think about allowing LKM-based LSMs a bit, you will find that how can the current policy be compatible. We cannot introduce lsm_get_self_attr()/lsm_set_self_attr()/lsm_list_modules() syscalls without admitting stable LSM ID values being assigned to any publicly available LSMs. Simple notification to the LSM community has to be the only requirement for assigning stable LSM ID values. You should not distinguish in-tree and not-in-tree LSMs regarding "[PATCH v15 00/11] LSM: Three basic syscalls". Otherwise, the attempt to introduce these syscalls is a regression that will harm LKM-based LSMs.
