[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <403108b1-5600-bb5e-a0ad-6f802b4b296f@gmail.com>
Date: Fri, 23 Jun 2023 18:10:11 -0700
From: Jay Freyensee <why2jjj.linux@...il.com>
To: Casey Schaufler <casey@...aufler-ca.com>, paul@...l-moore.com,
linux-security-module@...r.kernel.org
Cc: jmorris@...ei.org, serge@...lyn.com, keescook@...omium.org,
john.johansen@...onical.com, penguin-kernel@...ove.sakura.ne.jp,
stephen.smalley.work@...il.com, linux-kernel@...r.kernel.org,
linux-api@...r.kernel.org, mic@...ikod.net
Subject: Re: [PATCH v11 00/11] LSM: Three basic syscalls
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
Powered by blists - more mailing lists