Re: [PATCH v26 02/25] LSM: Add the lsmblob data structure.
From: Mickaël Salaün
Date: Wed May 26 2021 - 05:51:02 EST
On 26/05/2021 01:52, Casey Schaufler wrote:
> On 5/22/2021 1:39 AM, Mickaël Salaün wrote:
>> I like this design but there is an issue with Landlock though, see below.
>>
>> On 13/05/2021 22:07, Casey Schaufler wrote:
>>> When more than one security module is exporting data to
>>> audit and networking sub-systems a single 32 bit integer
>>> is no longer sufficient to represent the data. Add a
>>> structure to be used instead.
>>>
>>> The lsmblob structure is currently an array of
>>> u32 "secids". There is an entry for each of the
>>> security modules built into the system that would
>>> use secids if active. The system assigns the module
>>> a "slot" when it registers hooks. If modules are
>>> compiled in but not registered there will be unused
>>> slots.
>>>
>>> A new lsm_id structure, which contains the name
>>> of the LSM and its slot number, is created. There
>>> is an instance for each LSM, which assigns the name
>>> and passes it to the infrastructure to set the slot.
>>>
>>> The audit rules data is expanded to use an array of
>>> security module data rather than a single instance.
>>> Because IMA uses the audit rule functions it is
>>> affected as well.
>>>
>>> Acked-by: Stephen Smalley <sds@xxxxxxxxxxxxx>
>>> Acked-by: Paul Moore <paul@xxxxxxxxxxxxxx>
>>> Acked-by: John Johansen <john.johansen@xxxxxxxxxxxxx>
>>> Signed-off-by: Casey Schaufler <casey@xxxxxxxxxxxxxxxx>
>>> Cc: <bpf@xxxxxxxxxxxxxxx>
>>> Cc: linux-audit@xxxxxxxxxx
>>> Cc: linux-security-module@xxxxxxxxxxxxxxx
>>> Cc: selinux@xxxxxxxxxxxxxxx
>>> To: Mimi Zohar <zohar@xxxxxxxxxxxxx>
>>> To: Mickaël Salaün <mic@xxxxxxxxxxxxxxxxxxx>
>>> ---
>>> include/linux/audit.h | 4 +-
>>> include/linux/lsm_hooks.h | 12 ++++-
>>> include/linux/security.h | 67 +++++++++++++++++++++++++--
>>> kernel/auditfilter.c | 24 +++++-----
>>> kernel/auditsc.c | 13 +++---
>>> security/apparmor/lsm.c | 7 ++-
>>> security/bpf/hooks.c | 12 ++++-
>>> security/commoncap.c | 7 ++-
>>> security/integrity/ima/ima_policy.c | 40 +++++++++++-----
>>> security/landlock/cred.c | 2 +-
>>> security/landlock/fs.c | 2 +-
>>> security/landlock/ptrace.c | 2 +-
>>> security/landlock/setup.c | 4 ++
>>> security/landlock/setup.h | 1 +
>>> security/loadpin/loadpin.c | 8 +++-
>>> security/lockdown/lockdown.c | 7 ++-
>>> security/safesetid/lsm.c | 8 +++-
>>> security/security.c | 72 ++++++++++++++++++++++++-----
>>> security/selinux/hooks.c | 8 +++-
>>> security/smack/smack_lsm.c | 7 ++-
>>> security/tomoyo/tomoyo.c | 8 +++-
>>> security/yama/yama_lsm.c | 7 ++-
>>> 22 files changed, 262 insertions(+), 60 deletions(-)
>>>
>> [...]
>>
>>> diff --git a/security/landlock/setup.c b/security/landlock/setup.c
>>> index f8e8e980454c..4a12666a4090 100644
>>> --- a/security/landlock/setup.c
>>> +++ b/security/landlock/setup.c
>>> @@ -23,6 +23,10 @@ struct lsm_blob_sizes landlock_blob_sizes __lsm_ro_after_init = {
>>> .lbs_superblock = sizeof(struct landlock_superblock_security),
>>> };
>>>
>>> +struct lsm_id landlock_lsmid __lsm_ro_after_init = {
>>> + .lsm = LANDLOCK_NAME,
>> It is missing: .slot = LSMBLOB_NEEDED,
>
> Sorry for the delay.
>
> Landlock does not provide any of the hooks that use a struct lsmblob.
> That would be secid_to_secctx, secctx_to_secid, inode_getsecid,
> cred_getsecid, kernel_act_as task_getsecid_subj task_getsecid_obj and
> ipc_getsecid. Setting .slot = LSMBLOB_NEEDED indicates that the LSM
> uses a slot in struct lsmblob. Landlock does not need a slot.
Indeed, the (generic) "blob" name misled me. Would it make sense to use
a name with "secid" in it instead?
Shouldn't the slot field be set to LSMBLOB_NOT_NEEDED (-3) then (instead
of the implicit 0)?
>
>>
>> You can run the Landlock tests please?
>> make -C tools/testing/selftests TARGETS=landlock gen_tar
>> tar -xf kselftest.tar.gz && ./run_kselftest.sh
>
> Sure. I'll add them to my routine.
Thanks.
>
>>
>>
>>> +};
>>> +
>>> static int __init landlock_init(void)
>>> {
>>> landlock_add_cred_hooks();
>> [...]
>>
>>> diff --git a/security/security.c b/security/security.c
>>> index e12a7c463468..a3276deb1b8a 100644
>>> --- a/security/security.c
>>> +++ b/security/security.c
>>> @@ -344,6 +344,7 @@ static void __init ordered_lsm_init(void)
>>> init_debug("sock blob size = %d\n", blob_sizes.lbs_sock);
>>> init_debug("superblock blob size = %d\n", blob_sizes.lbs_superblock);
>>> init_debug("task blob size = %d\n", blob_sizes.lbs_task);
>>> + init_debug("lsmblob size = %zu\n", sizeof(struct lsmblob));
>>>
>>> /*
>>> * Create any kmem_caches needed for blobs
>>> @@ -471,21 +472,36 @@ static int lsm_append(const char *new, char **result)
>>> return 0;
>>> }
>>>
>>> +/*
>>> + * Current index to use while initializing the lsmblob secid list.
>>> + */
>>> +static int lsm_slot __lsm_ro_after_init;
>>> +
>>> /**
>>> * security_add_hooks - Add a modules hooks to the hook lists.
>>> * @hooks: the hooks to add
>>> * @count: the number of hooks to add
>>> - * @lsm: the name of the security module
>>> + * @lsmid: the identification information for the security module
>>> *
>>> * Each LSM has to register its hooks with the infrastructure.
>>> + * If the LSM is using hooks that export secids allocate a slot
>>> + * for it in the lsmblob.
>>> */
>>> void __init security_add_hooks(struct security_hook_list *hooks, int count,
>>> - char *lsm)
>>> + struct lsm_id *lsmid)
>>> {
>>> int i;
>>>
>> Could you add a WARN_ON(!lsmid->slot || !lsmid->name) here?
>
> Yes. That's reasonable.
I guess my above comment makes sense if lsmid->slot should not be zero
but LSMBLOB_NOT_NEEDED instead, otherwise the Landlock lsmid would throw
a warning.
>
>>
>>
>>> + if (lsmid->slot == LSMBLOB_NEEDED) {
>>> + if (lsm_slot >= LSMBLOB_ENTRIES)
>>> + panic("%s Too many LSMs registered.\n", __func__);
>>> + lsmid->slot = lsm_slot++;
>>> + init_debug("%s assigned lsmblob slot %d\n", lsmid->lsm,
>>> + lsmid->slot);
>>> + }
>>> +
>>> for (i = 0; i < count; i++) {
>>> - hooks[i].lsm = lsm;
>>> + hooks[i].lsmid = lsmid;
>>> hlist_add_tail_rcu(&hooks[i].list, hooks[i].head);
>>> }
>>>
>