Re: [PATCH v4 10/20] lsm: Refactor return value of LSM hook audit_rule_match

Paul Moore
2024-07-19T02:08:10Z

On Jul 11, 2024 Xu Kuohai <xukuohai@huaweicloud.com> wrote:
>
> To be consistent with most LSM hooks, convert the return value of
> hook audit_rule_match to 0 or a negative error code.
>
> Before:
> - Hook audit_rule_match returns 1 if the rule matches, 0 if it not,
> and negative error code otherwise.
>
> After:
> - Hook audit_rule_match returns 0 on success or a negative error
> code on failure. An output parameter @match is introduced to hold
> the match result on success.
>
> Signed-off-by: Xu Kuohai <xukuohai@huawei.com>
> ---
> include/linux/lsm_hook_defs.h | 3 +-
> security/apparmor/audit.c | 22 ++++++-------
> security/apparmor/include/audit.h | 2 +-
> security/security.c | 15 ++++++++-
> security/selinux/include/audit.h | 8 +++--
> security/selinux/ss/services.c | 54 +++++++++++++++++--------------
> security/smack/smack_lsm.c | 19 +++++++----
> 7 files changed, 75 insertions(+), 48 deletions(-)

This is another odd hook, and similar to some of the others in this
patchset, I'm not sure how applicable this would be to a BPF-based
LSM. I suspect you could safely block this from a BPF LSM and no one
would notice or be upset.

However, if we did want to keep this hook for a BPF LSM, I think it
might be better to encode the "match" results in the return value, just
sticking with a more conventional 0/errno approach. What do you think
about 0:found/ok, -ENOENT:missing/ok, -ERRNO:other/error? Yes, some
of the existing LSM audit_match code uses -ENOENT but looking quickly
at those error conditions it seems that we could consider them
equivalent to a "missing" or "failed match" result and use -ENOENT for
both. If you're really not happy with that overloading, we could use
something like -ENOMSG:missing/ok instead.

Thoughts?

--
paul-moore.com