Re: [PATCH v11 00/11] LSM: Three basic syscalls

From: Jay Freyensee
Date: Fri Jun 23 2023 - 21:10:23 EST



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?

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.


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?

Thanks,

Jay