Re: [PATCH v4 10/20] lsm: Refactor return value of LSM hook audit_rule_match
From: Xu Kuohai <xukuohai@huaweicloud.com>
Date: 2024-07-20 09:31:18
Also in:
bpf, linux-integrity, linux-kselftest, linux-security-module, selinux
On 7/19/2024 10:08 AM, Paul Moore wrote:
On Jul 11, 2024 Xu Kuohai [off-list ref] wrote:quoted
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 <redacted> --- 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?
I think we could just block it and see what happens.
-- paul-moore.com