linux.git/security/integrity, branch v6.10-rc2

ima: add crypto agility support for template-hash algorithm

2024-04-12T13:59:04+00:00

The template hash showed by the ascii_runtime_measurements and
binary_runtime_measurements is the one calculated using sha1 and there is
no possibility to change this value, despite the fact that the template
hash is calculated using the hash algorithms corresponding to all the PCR
banks configured in the TPM.

Add the support to retrieve the ima log with the template data hash
calculated with a specific hash algorithm.
Add a new file in the securityfs ima directory for each hash algo
configured in a PCR bank of the TPM. Each new file has the name with
the following structure:

        {binary, ascii}_runtime_measurements_

Legacy files are kept, to avoid breaking existing applications, but as
symbolic links which point to {binary, ascii}_runtime_measurements_sha1
files. These two files are created even if a TPM chip is not detected or
the sha1 bank is not configured in the TPM.

As example, in the case a TPM chip is present and sha256 is the only
configured PCR bank, the listing of the securityfs ima directory is the
following:

lr--r--r-- [...] ascii_runtime_measurements -> ascii_runtime_measurements_sha1
-r--r----- [...] ascii_runtime_measurements_sha1
-r--r----- [...] ascii_runtime_measurements_sha256
lr--r--r-- [...] binary_runtime_measurements -> binary_runtime_measurements_sha1
-r--r----- [...] binary_runtime_measurements_sha1
-r--r----- [...] binary_runtime_measurements_sha256
--w------- [...] policy
-r--r----- [...] runtime_measurements_count
-r--r----- [...] violations

Signed-off-by: Enrico Bravi 
Signed-off-by: Silvia Sisinni 
Reviewed-by: Roberto Sassu 
Signed-off-by: Mimi Zohar

evm: Rename is_unsupported_fs to is_unsupported_hmac_fs

2024-04-09T21:14:58+00:00

Rename is_unsupported_fs to is_unsupported_hmac_fs since now only HMAC is
unsupported.

Co-developed-by: Mimi Zohar 
Signed-off-by: Stefan Berger 
Signed-off-by: Mimi Zohar

fs: Rename SB_I_EVM_UNSUPPORTED to SB_I_EVM_HMAC_UNSUPPORTED

2024-04-09T21:14:58+00:00

Now that EVM supports RSA signatures for previously completely
unsupported filesystems rename the flag SB_I_EVM_UNSUPPORTED to
SB_I_EVM_HMAC_UNSUPPORTED to reflect that only HMAC is not supported.

Suggested-by: Amir Goldstein 
Suggested-by: Mimi Zohar 
Signed-off-by: Stefan Berger 
Acked-by: Amir Goldstein 
Signed-off-by: Mimi Zohar

evm: Enforce signatures on unsupported filesystem for EVM_INIT_X509

2024-04-09T21:14:57+00:00

Unsupported filesystems currently do not enforce any signatures. Add
support for signature enforcement of the "original" and "portable &
immutable" signatures when EVM_INIT_X509 is enabled.

The "original" signature type contains filesystem specific metadata.
Thus it cannot be copied up and verified. However with EVM_INIT_X509
and EVM_ALLOW_METADATA_WRITES enabled, the "original" file signature
may be written.

When EVM_ALLOW_METADATA_WRITES is not set or once it is removed from
/sys/kernel/security/evm by setting EVM_INIT_HMAC for example, it is not
possible to write or remove xattrs on the overlay filesystem.

This change still prevents EVM from writing HMAC signatures on
unsupported filesystem when EVM_INIT_HMAC is enabled.

Co-developed-by: Mimi Zohar 
Signed-off-by: Stefan Berger 
Signed-off-by: Mimi Zohar

ima: re-evaluate file integrity on file metadata change

2024-04-09T21:14:57+00:00

Force a file's integrity to be re-evaluated on file metadata change by
resetting both the IMA and EVM status flags.

Co-developed-by: Mimi Zohar 
Signed-off-by: Stefan Berger 
Signed-off-by: Mimi Zohar

evm: Store and detect metadata inode attributes changes

2024-04-09T21:14:57+00:00

On stacked filesystem the metadata inode may be different than the one
file data inode and therefore changes to it need to be detected
independently. Therefore, store the i_version, device number, and inode
number associated with the file metadata inode.

Implement a function to detect changes to the inode and if a change is
detected reset the evm_status. This function will be called by IMA when
IMA detects that the metadata inode is different from the file's inode.

Co-developed-by: Mimi Zohar 
Signed-off-by: Stefan Berger 
Signed-off-by: Mimi Zohar

ima: Move file-change detection variables into new structure

2024-04-09T21:14:57+00:00

Move all the variables used for file change detection into a structure
that can be used by IMA and EVM. Implement an inline function for storing
the identification of an inode and one for detecting changes to an inode
based on this new structure.

Co-developed-by: Mimi Zohar 
Signed-off-by: Stefan Berger 
Signed-off-by: Mimi Zohar

evm: Use the metadata inode to calculate metadata hash

2024-04-09T21:14:57+00:00

Changes to file attributes (mode bits, uid, gid) on the lower layer are
not taken into account when d_backing_inode() is used when a file is
accessed on the overlay layer and this file has not yet been copied up.
This is because d_backing_inode() does not return the real inode of the
lower layer but instead returns the backing inode which in this case
holds wrong file attributes. Further, when CONFIG_OVERLAY_FS_METACOPY is
enabled and a copy-up is triggered due to file metadata changes, then
the metadata are held by the backing inode while the data are still held
by the real inode. Therefore, use d_inode(d_real(dentry, D_REAL_METADATA))
to get to the file's metadata inode and use it to calculate the metadata
hash with.

Co-developed-by: Mimi Zohar 
Signed-off-by: Stefan Berger 
Acked-by: Amir Goldstein 
Signed-off-by: Mimi Zohar

evm: Implement per signature type decision in security_inode_copy_up_xattr

2024-04-09T21:14:57+00:00

To support "portable and immutable signatures" on otherwise unsupported
filesystems, determine the EVM signature type by the content of a file's
xattr. If the file has the appropriate signature type then allow it to be
copied up. All other signature types are discarded as before.

"Portable and immutable" EVM signatures can be copied up by stacked file-
system since the metadata their signature covers does not include file-
system-specific data such as a file's inode number, generation, and UUID.

Co-developed-by: Mimi Zohar 
Signed-off-by: Stefan Berger 
Signed-off-by: Mimi Zohar

security: allow finer granularity in permitting copy-up of security xattrs

2024-04-09T21:14:57+00:00

Copying up xattrs is solely based on the security xattr name. For finer
granularity add a dentry parameter to the security_inode_copy_up_xattr
hook definition, allowing decisions to be based on the xattr content as
well.

Co-developed-by: Mimi Zohar 
Signed-off-by: Stefan Berger 
Acked-by: Amir Goldstein 
Acked-by: Paul Moore  (LSM,SELinux)
Signed-off-by: Mimi Zohar