On 6/23/2023 6:10 PM, Jay Freyensee wrote: > > On 6/16/23 9:50 AM, Casey Schaufler wrote: >> Add three system calls for the Linux Security Module ABI. >> >> lsm_get_self_attr() provides the security module specific attributes >> that have previously been visible in the /proc/self/attr directory. >> For each security module that uses the specified attribute on the >> current process the system call will return an LSM identifier and >> the value of the attribute. The LSM and attribute identifier values >> are defined in include/uapi/linux/lsm.h >> >> LSM identifiers are simple integers and reflect the order in which >> the LSM was added to the mainline kernel. This is a convention, not >> a promise of the API. LSM identifiers below the value of 100 are >> reserved for unspecified future uses. That could include information >> about the security infrastructure itself, or about how multiple LSMs >> might interact with each other. >> >> A new LSM hook security_getselfattr() is introduced to get the >> required information from the security modules. This is similar >> to the existing security_getprocattr() hook, but specifies the >> format in which string data is returned and requires the module >> to put the information into a userspace destination. >> >> lsm_set_self_attr() changes the specified LSM attribute. Only one >> attribute can be changed at a time, and then only if the specified >> security module allows the change. >> >> A new LSM hook security_setselfattr() is introduced to set the >> required information in the security modules. This is similar >> to the existing security_setprocattr() hook, but specifies the >> format in which string data is presented and requires the module >> to get the information from a userspace destination. >> >> lsm_list_modules() provides the LSM identifiers, in order, of the >> security modules that are active on the system. This has been >> available in the securityfs file /sys/kernel/security/lsm. > Active or available? Active. Security modules are registered during init time. There isn't really a notion of "available" since you can't enable or disable them dynamically. > > If I use landlock's documentation example: > > Jun 07 10:37:11 fedora kernel: LSM: initializing > lsm=lockdown,capability,yama,integrity,selinux,bpf> > Jun 07 10:37:11 fedora kernel: landlock: Up and running. > > My interpretation of the two log lines is the first line tells me > landlock is available on the distro (fedora this case), but the second > line tells me landlock is now active. Thus the lsm available list may > be different than the lsm active list. Your "available" list would depend on which modules are compiled in. There is no explicit mechanism provided to get that list. There isn't anything interesting you could do with it on a running system. > > So is lsm_list_modules() going to tell me just what lsm's are > available in a distro for use, or is it going to tell me what lsm's > are available _and_ active? As documented, its going to tell you which are active. You can infer that a module is available if it is active. You cannot infer that a module isn't "available", that is, isn't compiled in, if it isn't active. > > Thanks, > > Jay >
