Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20230629195535.2590-1-casey@schaufler-ca.com> <20230629195535.2590-3-casey@schaufler-ca.com>
 <9b09c571-9288-73e1-18c5-9023b909a5d9@digikod.net> <b711f8b4-f624-bb2b-1caf-90c674245135@schaufler-ca.com>
In-Reply-To: <b711f8b4-f624-bb2b-1caf-90c674245135@schaufler-ca.com>
From:   Paul Moore <paul@paul-moore.com>
Date:   Fri, 21 Jul 2023 17:40:23 -0400
Message-ID: <CAHC9VhRY1_tdLVnFGK4ZxRDEs+JKJWD3VR+iHrcrm9Psmbowtg@mail.gmail.com>
Subject: Re: [PATCH v12 02/11] LSM: Maintain a table of LSM attribute data
To:     Casey Schaufler <casey@schaufler-ca.com>
Cc:     =?UTF-8?B?TWlja2HDq2wgU2FsYcO8bg==?= <mic@digikod.net>,
        linux-security-module@vger.kernel.org, jmorris@namei.org,
        serge@hallyn.com, keescook@chromium.org,
        john.johansen@canonical.com, penguin-kernel@i-love.sakura.ne.jp,
        stephen.smalley.work@gmail.com, linux-kernel@vger.kernel.org,
        linux-api@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Fri, Jul 14, 2023 at 3:42=E2=80=AFPM Casey Schaufler <casey@schaufler-ca=
.com> wrote:
> On 7/11/2023 8:35 AM, Micka=C3=ABl Sala=C3=BCn 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@schaufler-ca.com>
> >> Reviewed-by: Kees Cook <keescook@chromium.org>
> >> Reviewed-by: Serge Hallyn <serge@hallyn.com>
> >> ---
> >>   include/linux/security.h |  2 ++
> >>   security/security.c      | 37 +++++++++++++++++++++++++++++++++++++
> >>   2 files changed, 39 insertions(+)

...

> >> diff --git a/security/security.c b/security/security.c
> >> index e56714ef045a..5a699e47478b 100644
> >> --- a/security/security.c
> >> +++ b/security/security.c
> >> @@ -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 =3D=3D 0 || lsm_idlist[lsm_active_cnt - 1] !=
=3D
> >> 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 >=3D 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=E2=80=A6
>
> It's possible this should be a BUG() instance, but the panic() more
> closely resembles what's nearby in the code.

I think the panic() call is okay.  If something is so horribly broken
that we hit this case we have little option but to panic the system as
booting with the LSM controls busted in such a way is very not good.

There are probably those that would object to the above statement, but
those people aren't likely to be building a kernel with any LSMs in
the first place.

--=20
paul-moore.com