Re: [PATCH 1/6] lsm: Add a capable_lsm hook for capabilities guarding an LSM's policy

[sashiko-bot@kernel.org]

> AppArmor, Smack and SELinux check the capabilities that guard their own
> policy (e.g. CAP_MAC_ADMIN, CAP_MAC_OVERRIDE, or CAP_SYS_PTRACE for
> Smack's ptrace rule) with cap_capable(), usually followed by their own
> internal check.  They use cap_capable() instead of capable() on purpose:
> other stacked LSMs should not have to authorize these capabilities,
> which may mean something else for their security model.  This also hides
> these capability uses from LSMs that restrict capability use in general:
> a Landlock domain that denies CAP_MAC_ADMIN does not prevent a process
> from managing AppArmor policy.
> 
> Add security_capable_lsm() for these checks, and a capable_lsm hook that
> it calls after cap_capable().  Only LSMs that implement this new hook
> see these checks, so LSMs that only implement the capable hook are still
> not asked about another LSM's policy, and the calling LSM's own capable
> hook is not called.  The hook gets the LSM_ID_* of the LSM whose policy
> [ ... ]
> Cc: Matt Bobrowski <matt@bobrowski.net>
> Cc: Paul Moore <paul@paul-moore.com>
> Cc: Serge Hallyn <serge@hallyn.com>
> Cc: Stephen Smalley <stephen.smalley.work@gmail.com>
> Signed-off-by: Mickaël Salaün <mic@digikod.net>

Sashiko has reviewed this patch and found no issues.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261110203042.2410140-1-mic@digikod.net?part=1