linux-kernel - Re: [PATCH v2 1/13] LSM: Add the lsmblob data structure.

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] [day] [month] [year] [list]

Message-ID: <CAHC9VhTwYftY4nLauF8A9AOawAGKdU-+TGoVfM7Paf23x1Vm8w@mail.gmail.com>
Date: Wed, 4 Sep 2024 16:36:59 -0400
From: Paul Moore <paul@...l-moore.com>
To: Casey Schaufler <casey@...aufler-ca.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
Subject: Re: [PATCH v2 1/13] LSM: Add the lsmblob data structure.

On Wed, Sep 4, 2024 at 4:28 PM Casey Schaufler <casey@...aufler-ca.com> wrote:
> 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.

Works for me, thanks Casey.

-- 
paul-moore.com