linux-kernel - Re: [PATCH v12 02/11] LSM: Maintain a table of LSM attribute data

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <b711f8b4-f624-bb2b-1caf-90c674245135@schaufler-ca.com>
Date:   Fri, 14 Jul 2023 12:42:27 -0700
From:   Casey Schaufler <casey@...aufler-ca.com>
To:     Mickaël Salaün <mic@...ikod.net>,
        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, Casey Schaufler <casey@...aufler-ca.com>
Subject: Re: [PATCH v12 02/11] LSM: Maintain a table of LSM attribute data

On 7/11/2023 8:35 AM, Mickaël Salaün wrote:
>
> On 29/06/2023 21:55, Casey Schaufler wrote:
>> As LSMs are registered add their lsm_id pointers to a table.
>> This will be used later for attribute reporting.
>>
>> Determine the number of possible security modules based on
>> their respective CONFIG options. This allows the number to be
>> known at build time. This allows data structures and tables
>> to use the constant.
>>
>> Signed-off-by: Casey Schaufler <casey@...aufler-ca.com>
>> Reviewed-by: Kees Cook <keescook@...omium.org>
>> Reviewed-by: Serge Hallyn <serge@...lyn.com>
>> ---
>>   include/linux/security.h |  2 ++
>>   security/security.c      | 37 +++++++++++++++++++++++++++++++++++++
>>   2 files changed, 39 insertions(+)
>>
>> diff --git a/include/linux/security.h b/include/linux/security.h
>> index e2734e9e44d5..569b1d8ab002 100644
>> --- a/include/linux/security.h
>> +++ b/include/linux/security.h
>> @@ -138,6 +138,8 @@ enum lockdown_reason {
>>   };
>>     extern const char *const
>> lockdown_reasons[LOCKDOWN_CONFIDENTIALITY_MAX+1];
>> +extern u32 lsm_active_cnt;
>> +extern struct lsm_id *lsm_idlist[];
>
> extern const struct lsm_id *lsm_idlist[];
>
>>     /* These functions are in security/commoncap.c */
>>   extern int cap_capable(const struct cred *cred, struct
>> user_namespace *ns,
>> diff --git a/security/security.c b/security/security.c
>> index e56714ef045a..5a699e47478b 100644
>> --- a/security/security.c
>> +++ b/security/security.c
>> @@ -36,6 +36,25 @@
>>   /* How many LSMs were built into the kernel? */
>>   #define LSM_COUNT (__end_lsm_info - __start_lsm_info)
>>   +/*
>> + * How many LSMs are built into the kernel as determined at
>> + * build time. Used to determine fixed array sizes.
>> + * The capability module is accounted for by CONFIG_SECURITY
>> + */
>> +#define LSM_CONFIG_COUNT ( \
>> +    (IS_ENABLED(CONFIG_SECURITY) ? 1 : 0) + \
>> +    (IS_ENABLED(CONFIG_SECURITY_SELINUX) ? 1 : 0) + \
>> +    (IS_ENABLED(CONFIG_SECURITY_SMACK) ? 1 : 0) + \
>> +    (IS_ENABLED(CONFIG_SECURITY_TOMOYO) ? 1 : 0) + \
>> +    (IS_ENABLED(CONFIG_IMA) ? 1 : 0) + \
>> +    (IS_ENABLED(CONFIG_SECURITY_APPARMOR) ? 1 : 0) + \
>> +    (IS_ENABLED(CONFIG_SECURITY_YAMA) ? 1 : 0) + \
>> +    (IS_ENABLED(CONFIG_SECURITY_LOADPIN) ? 1 : 0) + \
>> +    (IS_ENABLED(CONFIG_SECURITY_SAFESETID) ? 1 : 0) + \
>> +    (IS_ENABLED(CONFIG_SECURITY_LOCKDOWN_LSM) ? 1 : 0) + \
>> +    (IS_ENABLED(CONFIG_BPF_LSM) ? 1 : 0) + \
>> +    (IS_ENABLED(CONFIG_SECURITY_LANDLOCK) ? 1 : 0))
>> +
>>   /*
>>    * These are descriptions of the reasons that can be passed to the
>>    * security_locked_down() LSM hook. Placing this array here allows
>> @@ -245,6 +264,12 @@ static void __init initialize_lsm(struct
>> lsm_info *lsm)
>>       }
>>   }
>>   +/*
>> + * Current index to use while initializing the lsm id list.
>> + */
>> +u32 lsm_active_cnt __ro_after_init;
>> +struct lsm_id *lsm_idlist[LSM_CONFIG_COUNT] __ro_after_init;
>
> const struct lsm_id *lsm_idlist[LSM_CONFIG_COUNT] __ro_after_init;
>
>
>> +
>>   /* Populate ordered LSMs list from comma-separated LSM name list. */
>>   static void __init ordered_lsm_parse(const char *order, const char
>> *origin)
>>   {
>> @@ -521,6 +546,18 @@ void __init security_add_hooks(struct
>> security_hook_list *hooks, int count,
>>   {
>>       int i;
>>   +    /*
>> +     * A security module may call security_add_hooks() more
>> +     * than once during initialization, and LSM initialization
>> +     * is serialized. Landlock is one such case.
>> +     * Look at the previous entry, if there is one, for duplication.
>> +     */
>> +    if (lsm_active_cnt == 0 || lsm_idlist[lsm_active_cnt - 1] !=
>> lsmid) {
>
> Isn't it possible to have interleaved security_add_hooks() calls?

The initialization is serial and interleaving isn't possible.

>
>
>> +        if (lsm_active_cnt >= LSM_CONFIG_COUNT)
>> +            panic("%s Too many LSMs registered.\n", __func__);
>
> I'm not sure we should panic, but from a security point of view it is
> critical enough…

It's possible this should be a BUG() instance, but the panic() more
closely resembles what's nearby in the code.

>
>
>> +        lsm_idlist[lsm_active_cnt++] = lsmid;
>> +    }
>> +
>>       for (i = 0; i < count; i++) {
>>           hooks[i].lsmid = lsmid;
>>           hlist_add_tail_rcu(&hooks[i].list, hooks[i].head);