On Tue, Mar 12, 2024 at 3:08 PM Fan Wu <wufan@xxxxxxxxxxxxxxxxxxx> wrote:
> We could also make security_inode_setsecurity() more generic instead of
> for xattr only, any suggestions?
For the sake of simplicity, since security_inode_setsecurity() doesn't
work, it probably makes more sense to create a new LSM hook rather
than make significant changes to security_inode_setsecurity().
I'm looking at the fsverity hook usage in this patch as well as the
device-mapper hook usage in 13/19 with security_bdev_setsecurity() and
I'm wondering if we could adopt a similar hook as we do with block
devices:
/* NOTE: these are just example values, more granularity would likely
be needed */
enum {
LSM_INTGR_DIGEST,
LSM_INTGR_SIG,
} lsm_intgr_type;
/**
* security_inode_integrity() - Set the inode's integrity data
* @inode: the inode
* @integrity_type: type of integrity, e.g. hash digest, signature, etc.
* @value: the integrity value
* @value: size of the integrity value
*
* Register a verified integrity measurement of an inode with the LSM.
*
* Return: Returns 0 on success, negative values on failure.
*/
int security_inode_integrity(struct inode *inode,
enum lsm_intgr_type type,
const void *value, size_t size)
... if the above makes sense, I'd probably adjust
security_bdev_setsecurity() both to have a similar name, e.g.
/inode/bdev/, as well as to take a lsm_intgr_type enum instead of the
character string ... unless we really need a character string for some
reason, in which case use a character string in both places.
--
paul-moore.com
