On 6/23/2023 6:10 PM, Jay Freyensee wrote:

On 6/16/23 9:50 AM, Casey Schaufler wrote:

quoted

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