Message-ID: <93952b9f-2e40-42fc-9a61-749b9c8ee306@schaufler-ca.com>
Date: Wed, 4 Sep 2024 13:28:00 -0700
From: Casey Schaufler <casey@...aufler-ca.com>
To: Paul Moore <paul@...l-moore.com>
Cc: linux-security-module@...r.kernel.org, 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, selinux@...r.kernel.org, mic@...ikod.net,
 apparmor@...ts.ubuntu.com, bpf@...r.kernel.org,
 Casey Schaufler <casey@...aufler-ca.com>
Subject: Re: [PATCH v2 1/13] LSM: Add the lsmblob data structure.

On 9/4/2024 1:00 PM, Paul Moore wrote:
> On Tue, Sep 3, 2024 at 8:53 PM Casey Schaufler <casey@...aufler-ca.com> wrote:
>> On 9/3/2024 5:18 PM, Paul Moore wrote:
>>> On Aug 29, 2024 Casey Schaufler <casey@...aufler-ca.com> wrote:
> ..
>
>>>> +/*
>>>> + * Data exported by the security modules
>>>> + */
>>>> +struct lsmblob {
>>>> +    struct lsmblob_selinux selinux;
>>>> +    struct lsmblob_smack smack;
>>>> +    struct lsmblob_apparmor apparmor;
>>>> +    struct lsmblob_bpf bpf;
>>>> +    struct lsmblob_scaffold scaffold;
>>>> +};
>>> Warning, top shelf bikeshedding follows ...
>> Not unexpected. :)
>>
>>> I believe that historically when we've talked about the "LSM blob" we've
>>> usually been referring to the opaque buffers used to store LSM state that
>>> we attach to a number of kernel structs using the `void *security` field.
>>>
>>> At least that is what I think of when I read "struct lsmblob", and I'd
>>> like to get ahead of the potential confusion while we still can.
>>>
>>> Casey, I'm sure you're priority is simply getting this merged and you
>>> likely care very little about the name (as long as it isn't too horrible),
>> I would reject lsmlatefordinner out of hand.
> Fair enough :)
>
>>> but what about "lsm_ref"?  Other ideas are most definitely welcome.
>> I'm not a fan of the underscore, and ref seems to imply memory management.
>> How about "struct lsmsecid", which is a nod to the past "u32 secid"?
>> Or, "struct lsmdata", "struct lsmid", "struct lsmattr".
>> I could live with "struct lsmref", I suppose, although it pulls me toward
>> "struct lsmreference", which is a bit long.
> For what it's worth, I do agree that "ref" is annoyingly similar to a
> reference counter, I don't love it here, but I'm having a hard time
> coming up with something appropriate.
>
> I also tend to like the underscore, at least in the struct name, as it
> matches well with the "lsm_ctx" struct we have as part of the UAPI.
> When we use the struct name in function names, feel free to drop the
> underscore, for example: "lsm_foo" -> "security_get_lsmfoo()".
>
> My first thought was for something like "lsmid" (ignoring the
> underscore debate), but we already have the LSM_ID_XXX defines which
> are something entirely different and I felt like we would be trading
> one source of confusion for another.  There is a similar problem with
> the LSM_ATTR_XXX defines.
>
> We also already have a "lsm_ctx" struct which sort of rules out
> "lsmctx" for what are hopefully obvious reasons.
>
> I'd also like to avoid anything involving "secid" or "secctx" simply
> because the whole point of this struct is to move past the idea of a
> single integer or string representing all of the LSM properties for an
> entity.
>
> I can understand "lsm_data", but that is more ambiguous than I would like.
>
> What about "lsm_prop" or "lsm_cred"?

If we ever do the same sort of thing for the existing blobs we're
going to need to have lsm_cred for the cred blob, so I shan't use
it here. I can live with lsm_prop, which shouldn't confuse too many
developers. We can start saying "property" in place of secid, which
would be a good thing.

Powered by blists - more mailing lists