[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c3423767-91df-4dc9-afe8-895540b185d7@schaufler-ca.com>
Date: Fri, 11 Oct 2024 09:34:01 -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,
Casey Schaufler <casey@...aufler-ca.com>
Subject: Re: [PATCH v4 4/13] Audit: maintain an lsm_prop in audit_context
On 10/11/2024 9:11 AM, Paul Moore wrote:
> On Fri, Oct 11, 2024 at 11:52 AM Casey Schaufler <casey@...aufler-ca.com> wrote:
>> On 10/10/2024 8:08 PM, Paul Moore wrote:
>>> On Oct 9, 2024 Casey Schaufler <casey@...aufler-ca.com> wrote:
>>>> Replace the secid value stored in struct audit_context with a struct
>>>> lsm_prop. Change the code that uses this value to accommodate the
>>>> change. security_audit_rule_match() expects a lsm_prop, so existing
>>>> scaffolding can be removed. A call to security_secid_to_secctx()
>>>> is changed to security_lsmprop_to_secctx(). The call to
>>>> security_ipc_getsecid() is scaffolded.
>>>>
>>>> A new function lsmprop_is_set() is introduced to identify whether
>>>> an lsm_prop contains a non-zero value.
>>>>
>>>> Signed-off-by: Casey Schaufler <casey@...aufler-ca.com>
>>>> ---
>>>> include/linux/security.h | 24 ++++++++++++++++++++++++
>>>> kernel/audit.h | 3 ++-
>>>> kernel/auditsc.c | 19 ++++++++-----------
>>>> 3 files changed, 34 insertions(+), 12 deletions(-)
> ..
>
>>>> +/**
>>>> + * lsmprop_is_set - report if there is a value in the lsm_prop
>>>> + * @prop: Pointer to the exported LSM data
>>>> + *
>>>> + * Returns true if there is a value set, false otherwise
>>>> + */
>>>> +static inline bool lsm_prop_is_set(struct lsm_prop *prop)
>>>> +{
>>>> + return false;
>>>> +}
>>> If we're going to call this lsmprop_is_set() (see 5/13), we really should
>>> name it that way to start in this patch.
>> Agreed. That's an unfortunate artifact of the lsmblob to lsm_prop name change.
>>
>>> Considering everything else in this patchset looks okay, if you want me
>>> to fix this up during the merge let me know.
>> I can do a v5 if that makes life easier, but if you're OK with fixing it
>> during the merge I'm completely fine with that. Thank you.
> For trivial things like this where I've already reviewed the full
> patchset it's easier/quicker if I just make the change as I can do it
> and not have to re-review everything. Otherwise it's another revision
> for you to post, me to review, etc.; granted in that case I'm really
> just diffing between v4 and v5, not really doing a full review unless
> something odd pops up in the diff, but I think you get the idea.
Indeed. Go forth and merge. Thanks again.
Powered by blists - more mailing lists