On 12/27/2023 11:52 AM, Mimi Zohar wrote:
On Tue, 2023-12-26 at 12:14 -0800, Casey Schaufler wrote:
On 12/26/2023 10:14 AM, Mimi Zohar wrote:
On Thu, 2023-12-14 at 18:08 +0100, Roberto Sassu wrote:
From: Roberto Sassu roberto.sassu@huawei.com
Move hardcoded IMA function calls (not appraisal-specific functions) from various places in the kernel to the LSM infrastructure, by introducing a new LSM named 'ima' (at the end of the LSM list and always enabled like 'integrity').
Having IMA before EVM in the Makefile is sufficient to preserve the relative order of the new 'ima' LSM in respect to the upcoming 'evm' LSM, and thus the order of IMA and EVM function calls as when they were hardcoded.
Make moved functions as static (except ima_post_key_create_or_update(), which is not in ima_main.c), and register them as implementation of the respective hooks in the new function init_ima_lsm().
A slight difference is that IMA and EVM functions registered for the inode_post_setattr, inode_post_removexattr, path_post_mknod, inode_post_create_tmpfile, inode_post_set_acl and inode_post_remove_acl won't be executed for private inodes. Since those inodes are supposed to be fs-internal, they should not be of interest of IMA or EVM. The S_PRIVATE flag is used for anonymous inodes, hugetlbfs, reiserfs xattrs, XFS scrub and kernel-internal tmpfs files.
Conditionally register ima_post_path_mknod() if CONFIG_SECURITY_PATH is enabled, otherwise the path_post_mknod hook won't be available.
Up to this point, enabling CONFIG_SECURITY_PATH was not required. By making it conditional on CONFIG_SECURITY_PATH, anyone enabling IMA will also need to enable CONFIG_SECURITY_PATH. Without it, new files will not be tagged as a "new" file.
Casey, Paul, how common is it today not to enable CONFIG_SECURITY_PATH? Will enabling it just for IMA be a problem?
Landlock, AppArmor and TOMOYO require it. Fedora enables Landlock and Ubuntu enables AppArmor. I expect that, except for "minimal" distributions, you won't get any push back. If a distribution is striving for minimal, it's not going to use IMA.
It makes me wonder if eliminating CONFIG_SECURITY_PATH might not be a rational alternative.
Embedded systems were the first to use IMA for file signature verification, not distros. Could they have enabled SELinux, lockdown, and IMA?
Yes, they could have. I know some have used Smack and some SELinux. That's not really relevant, as neither of those use path hooks. My thought is that CONFIG_SECURITY_PATH adds more aggravation than value, but I can't quote numbers on either. I don't see a problem with IMA using path hooks. I also wouldn't see harm in moving the hook(s) you need for IMA out from that configuration option and into the general set. With the current rate of new hook additions I can't see moving an existing hook as a problem.