linux.git/security/integrity/ima/ima.h, branch v6.9

ima: Make it independent from 'integrity' LSM

2024-02-16T04:43:47+00:00

Make the 'ima' LSM independent from the 'integrity' LSM by introducing IMA
own integrity metadata (ima_iint_cache structure, with IMA-specific fields
from the integrity_iint_cache structure), and by managing it directly from
the 'ima' LSM.

Create ima_iint.c and introduce the same integrity metadata management
functions found in iint.c (renamed with ima_). However, instead of putting
metadata in an rbtree, reserve space from IMA in the inode security blob
for a pointer, and introduce the ima_inode_set_iint()/ima_inode_get_iint()
primitives to store/retrieve that pointer. This improves search time from
logarithmic to constant.

Consequently, don't include the inode pointer as field in the
ima_iint_cache structure, since the association with the inode is clear.
Since the inode field is missing in ima_iint_cache, pass the extra inode
parameter to ima_get_verity_digest().

Prefer storing the pointer instead of the entire ima_iint_cache structure,
to avoid too much memory pressure. Use the same mechanism as before, a
cache named ima_iint_cache (renamed from iint_cache), to quickly allocate
a new ima_iint_cache structure when requested by the IMA policy.

Create the new ima_iint_cache in ima_iintcache_init(),
called by init_ima_lsm(), during the initialization of the 'ima' LSM. And,
register ima_inode_free_security() to free the ima_iint_cache structure, if
exists.

Replace integrity_iint_cache with ima_iint_cache in various places of the
IMA code. Also, replace integrity_inode_get() and integrity_iint_find(),
respectively with ima_inode_get() and ima_iint_find().

Finally, move the remaining IMA-specific flags
to security/integrity/ima/ima.h, since they are now unnecessary in the
common integrity layer.

Signed-off-by: Roberto Sassu 
Reviewed-by: Casey Schaufler 
Reviewed-by: Stefan Berger 
Reviewed-by: Mimi Zohar 
Acked-by: Mimi Zohar 
Signed-off-by: Paul Moore

ima: Move IMA-Appraisal to LSM infrastructure

2024-02-16T04:43:46+00:00

A few additional IMA hooks are needed to reset the cached appraisal
status, causing the file's integrity to be re-evaluated on next access.
Register these IMA-appraisal only functions separately from the rest of IMA
functions, as appraisal is a separate feature not necessarily enabled in
the kernel configuration.

Reuse the same approach as for other IMA functions, move hardcoded calls
from various places in the kernel to the LSM infrastructure. Declare the
functions as static and register them as hook implementations in
init_ima_appraise_lsm(), called by init_ima_lsm().

Also move the inline function ima_inode_remove_acl() from the public ima.h
header to ima_appraise.c.

Signed-off-by: Roberto Sassu 
Reviewed-by: Stefan Berger 
Reviewed-by: Mimi Zohar 
Reviewed-by: Casey Schaufler 
Acked-by: Christian Brauner 
Acked-by: Mimi Zohar 
Signed-off-by: Paul Moore

ima: Move to LSM infrastructure

2024-02-16T04:43:46+00:00

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().

Select CONFIG_SECURITY_PATH, to ensure that the path-based LSM hook
path_post_mknod is always available and ima_post_path_mknod() is always
executed to mark files as new, as before the move.

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 to 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_key_create_or_update() if
CONFIG_IMA_MEASURE_ASYMMETRIC_KEYS is enabled. Also, conditionally register
ima_kernel_module_request() if CONFIG_INTEGRITY_ASYMMETRIC_KEYS is enabled.

Finally, add the LSM_ID_IMA case in lsm_list_modules_test.c.

Signed-off-by: Roberto Sassu 
Acked-by: Chuck Lever 
Acked-by: Casey Schaufler 
Acked-by: Christian Brauner 
Reviewed-by: Stefan Berger 
Reviewed-by: Mimi Zohar 
Acked-by: Mimi Zohar 
Signed-off-by: Paul Moore

Merge tag 'integrity-v6.3' of git://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity

2023-02-22T20:36:25+00:00

Pull integrity update from Mimi Zohar:
 "One doc and one code cleanup, and two bug fixes"

* tag 'integrity-v6.3' of git://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity:
  ima: Introduce MMAP_CHECK_REQPROT hook
  ima: Align ima_file_mmap() parameters with mmap_file LSM hook
  evm: call dump_security_xattr() in all cases to remove code duplication
  ima: fix ima_delete_rules() kernel-doc warning
  ima: return IMA digest value only when IMA_COLLECTED flag is set
  ima: fix error handling logic when file measurement failed

ima: Introduce MMAP_CHECK_REQPROT hook

2023-01-31T18:08:39+00:00

Commit 98de59bfe4b2f ("take calculation of final prot in
security_mmap_file() into a helper") caused ima_file_mmap() to receive the
protections requested by the application and not those applied by the
kernel.

After restoring the original MMAP_CHECK behavior, existing attestation
servers might be broken due to not being ready to handle new entries
(previously missing) in the IMA measurement list.

Restore the original correct MMAP_CHECK behavior, instead of keeping the
current buggy one and introducing a new hook with the correct behavior.
Otherwise, there would have been the risk of IMA users not noticing the
problem at all, as they would actively have to update the IMA policy, to
switch to the correct behavior.

Also, introduce the new MMAP_CHECK_REQPROT hook to keep the current
behavior, so that IMA users could easily fix a broken attestation server,
although this approach is discouraged due to potentially missing
measurements.

Signed-off-by: Roberto Sassu 
Signed-off-by: Mimi Zohar

fs: port xattr to mnt_idmap

2023-01-19T08:24:28+00:00

Convert to struct mnt_idmap.

Last cycle we merged the necessary infrastructure in
256c8aed2b42 ("fs: introduce dedicated idmap type for mounts").
This is just the conversion to struct mnt_idmap.

Currently we still pass around the plain namespace that was attached to a
mount. This is in general pretty convenient but it makes it easy to
conflate namespaces that are relevant on the filesystem with namespaces
that are relevent on the mount level. Especially for non-vfs developers
without detailed knowledge in this area this can be a potential source for
bugs.

Once the conversion to struct mnt_idmap is done all helpers down to the
really low-level helpers will take a struct mnt_idmap argument instead of
two namespace arguments. This way it becomes impossible to conflate the two
eliminating the possibility of any bugs. All of the vfs and all filesystems
only operate on struct mnt_idmap.

Acked-by: Dave Chinner 
Reviewed-by: Christoph Hellwig 
Signed-off-by: Christian Brauner (Microsoft)

lsm,fs: fix vfs_getxattr_alloc() return type and caller error paths

2022-11-18T22:07:03+00:00

The vfs_getxattr_alloc() function currently returns a ssize_t value
despite the fact that it only uses int values internally for return
values.  Fix this by converting vfs_getxattr_alloc() to return an
int type and adjust the callers as necessary.  As part of these
caller modifications, some of the callers are fixed to properly free
the xattr value buffer on both success and failure to ensure that
memory is not leaked in the failure case.

Reviewed-by: Serge Hallyn 
Reviewed-by: Mimi Zohar 
Signed-off-by: Paul Moore

IMA: introduce a new policy option func=SETXATTR_CHECK

2021-08-16T21:35:35+00:00

While users can restrict the accepted hash algorithms for the
security.ima xattr file signature when appraising said file, users
cannot restrict the algorithms that can be set on that attribute:
any algorithm built in the kernel is accepted on a write.

Define a new value for the ima policy option 'func' that restricts
globally the hash algorithms accepted when writing the security.ima
xattr.

When a policy contains a rule of the form
	appraise func=SETXATTR_CHECK appraise_algos=sha256,sha384,sha512
only values corresponding to one of these three digest algorithms
will be accepted for writing the security.ima xattr.  Attempting to
write the attribute using another algorithm (or "free-form" data)
will be denied with an audit log message.  In the absence of such a
policy rule, the default is still to only accept hash algorithms
built in the kernel (with all the limitations that entails).

Signed-off-by: THOBY Simon 
Reviewed-by: Lakshmi Ramasubramanian 
Signed-off-by: Mimi Zohar

IMA: add support to restrict the hash algorithms used for file appraisal

2021-08-16T21:30:41+00:00

The kernel accepts any hash algorithm as a value for the security.ima
xattr. Users may wish to restrict the accepted algorithms to only
support strong cryptographic ones.

Provide the plumbing to restrict the permitted set of hash algorithms
used for verifying file hashes and signatures stored in security.ima
xattr.

Signed-off-by: THOBY Simon 
Reviewed-by: Lakshmi Ramasubramanian 
Signed-off-by: Mimi Zohar

IMA: block writes of the security.ima xattr with unsupported algorithms

2021-08-16T21:30:41+00:00

By default, writes to the extended attributes security.ima will be
allowed even if the hash algorithm used for the xattr is not compiled
in the kernel (which does not make sense because the kernel would not
be able to appraise that file as it lacks support for validating the
hash).

Prevent and audit writes to the security.ima xattr if the hash algorithm
used in the new value is not available in the current kernel.

Signed-off-by: THOBY Simon 
Reviewed-by: Lakshmi Ramasubramanian 
Signed-off-by: Mimi Zohar