Hi Roberto,
Subject: -> security: Limit security_path_post_mknod() to regular files
This patch description was written for the previous patch version with minor
changes. The discussion was more about making LSM hooks more generic than
currently needed. The patch description should somehow reflect that discussion.
On Wed, 2024-04-03 at 11:07 +0200, Roberto Sassu wrote:
> From: Roberto Sassu <roberto.sassu@xxxxxxxxxx>
>
> Commit 08abce60d63f ("security: Introduce path_post_mknod hook")
> introduced security_path_post_mknod(), to replace the IMA-specific call to
> ima_post_path_mknod().
>
> For symmetry with security_path_mknod(), security_path_post_mknod() was
> called after a successful mknod operation, for any file type, rather than
> only for regular files at the time there was the IMA call.
-> rather than only for regular files.
>
> However, as reported by VFS maintainers, successful mknod operation does
> not mean that the dentry always has an inode attached to it (for example,
> not for FIFOs on a SAMBA mount).
>
> If that condition happens, the kernel crashes when
> security_path_post_mknod() attempts to verify if the inode associated to
> the dentry is private.
This is an example of why making the LSM hook more generic than needed didn't
work. Based on the discussion there is no valid reason for making the hook more
generic.
>
> Move security_path_post_mknod() where the ima_post_path_mknod() call was,
> which is obviously correct from IMA/EVM perspective. IMA/EVM are the only
> in-kernel users, and only need to inspect regular files.
-> Move the security_path_post_mknod() back to the original placement of the
ima_post_path_mknod(), so that it is only called for regular files.
>
> Reported-by: Steve French <smfrench@xxxxxxxxx>
> Closes:
> https://lore.kernel.org/linux-kernel/CAH2r5msAVzxCUHHG8VKrMPUKQHmBpE6K9_vjhgDa1uAvwx4ppw@xxxxxxxxxxxxxx/
> Suggested-by: Al Viro <viro@xxxxxxxxxxxxxxxxxx>
> Fixes: 08abce60d63f ("security: Introduce path_post_mknod hook")
> Signed-off-by: Roberto Sassu <roberto.sassu@xxxxxxxxxx>
Reviewed-by: Mimi Zohar <zohar@xxxxxxxxxxxxx>
