linux/security/integrity/evm, branch v5.14

evm: Check xattr size discrepancy between kernel and user

2021-06-21T12:34:21Z

The kernel and the user obtain an xattr value in two different ways: kernel (EVM): uses vfs_getxattr_alloc() which obtains the xattr value from the filesystem handler (raw value); user (ima-evm-utils): uses vfs_getxattr() which obtains the xattr value from the LSMs (normalized value). Normally, this does not have an impact unless security.selinux is set with setfattr, with a value not terminated by '\0' (this is not the recommended way, security.selinux should be set with the appropriate tools such as chcon and restorecon). In this case, the kernel and the user see two different xattr values: the former sees the xattr value without '\0' (raw value), the latter sees the value with '\0' (value normalized by SELinux). This could result in two different verification outcomes from EVM and ima-evm-utils, if a signature was calculated with a security.selinux value terminated by '\0' and the value set in the filesystem is not terminated by '\0'. The former would report verification failure due to the missing '\0', while the latter would report verification success (because it gets the normalized value with '\0'). This patch mitigates this issue by comparing in evm_calc_hmac_or_hash() the size of the xattr returned by the two xattr functions and by warning the user if there is a discrepancy. Signed-off-by: Roberto Sassu Suggested-by: Mimi Zohar Signed-off-by: Mimi Zohar

evm: output EVM digest calculation info

2021-06-20T15:10:25Z

Output the data used in calculating the EVM digest and the resulting digest as ascii hexadecimal strings. Suggested-by: Lakshmi Ramasubramanian (CONFIG_DYNAMIC_DEBUG) Reviewed-by: Lakshmi Ramasubramanian Reported-by: kernel test robot (Use %zu for size_t) Signed-off-by: Mimi Zohar

ima/evm: Fix type mismatch

2021-06-08T20:29:10Z

The endianness of a variable written to the measurement list cannot be determined at compile time, as it depends on the value of the ima_canonical_fmt global variable (set through a kernel option with the same name if the machine is big endian). If ima_canonical_fmt is false, the endianness of a variable is the same as the machine; if ima_canonical_fmt is true, the endianness is little endian. The warning arises due to this type of instruction: var = cpu_to_leXX(var) which tries to assign a value in little endian to a variable with native endianness (little or big endian). Given that the variables set with this instruction are not used in any operation but just written to a buffer, it is safe to force the type of the value being set to be the same of the type of the variable with: var = (__force )cpu_to_leXX(var) Reported-by: kernel test robot Signed-off-by: Roberto Sassu Signed-off-by: Mimi Zohar

evm: Don't return an error in evm_write_xattrs() if audit is not enabled

2021-06-03T14:03:40Z

This patch avoids that evm_write_xattrs() returns an error when audit is not enabled. The ab variable can be NULL and still be passed to the other audit_log_() functions, as those functions do not include any instruction. Signed-off-by: Roberto Sassu Signed-off-by: Mimi Zohar

ima: Define new template fields xattrnames, xattrlengths and xattrvalues

2021-06-02T22:56:13Z

This patch defines the new template fields xattrnames, xattrlengths and xattrvalues, which contain respectively a list of xattr names (strings, separated by |), lengths (u32, hex) and values (hex). If an xattr is not present, the name and length are not displayed in the measurement list. Reported-by: kernel test robot (Missing prototype def) Signed-off-by: Roberto Sassu Signed-off-by: Mimi Zohar

evm: Verify portable signatures against all protected xattrs

2021-06-01T19:17:31Z

Currently, the evm_config_default_xattrnames array contains xattr names only related to LSMs which are enabled in the kernel configuration. However, EVM portable signatures do not depend on local information and a vendor might include in the signature calculation xattrs that are not enabled in the target platform. Just including all xattrs names in evm_config_default_xattrnames is not a safe approach, because a target system might have already calculated signatures or HMACs based only on the enabled xattrs. After applying this patch, EVM would verify those signatures and HMACs with all xattrs instead. The non-enabled ones, which could possibly exist, would cause a verification error. Thus, this patch adds a new field named enabled to the xattr_list structure, which is set to true if the LSM associated to a given xattr name is enabled in the kernel configuration. The non-enabled xattrs are taken into account only in evm_calc_hmac_or_hash(), if the passed security.evm type is EVM_XATTR_PORTABLE_DIGSIG. The new function evm_protected_xattr_if_enabled() has been defined so that IMA can include all protected xattrs and not only the enabled ones in the measurement list, if the new template fields xattrnames, xattrlengths or xattrvalues have been included in the template format. Signed-off-by: Roberto Sassu Signed-off-by: Mimi Zohar

evm: Allow setxattr() and setattr() for unmodified metadata

2021-06-01T16:28:34Z

With the patch to allow xattr/attr operations if a portable signature verification fails, cp and tar can copy all xattrs/attrs so that at the end of the process verification succeeds. However, it might happen that the xattrs/attrs are already set to the correct value (taken at signing time) and signature verification succeeds before the copy has completed. For example, an archive might contains files owned by root and the archive is extracted by root. Then, since portable signatures are immutable, all subsequent operations fail (e.g. fchown()), even if the operation is legitimate (does not alter the current value). This patch avoids this problem by reporting successful operation to user space when that operation does not alter the current value of xattrs/attrs. With this patch, the one that introduces evm_hmac_disabled() and the one that allows a metadata operation on the INTEGRITY_FAIL_IMMUTABLE error, EVM portable signatures can be used without disabling metadata verification (by setting EVM_ALLOW_METADATA_WRITES). Due to keeping metadata verification enabled, altering immutable metadata protected with a portable signature that was successfully verified will be denied (existing behavior). Reported-by: kernel test robot [implicit declaration of function] Signed-off-by: Roberto Sassu Reviewed-by: Christian Brauner Cc: Andreas Gruenbacher Signed-off-by: Mimi Zohar

evm: Pass user namespace to set/remove xattr hooks

2021-05-21T16:57:52Z

In preparation for 'evm: Allow setxattr() and setattr() for unmodified metadata', this patch passes mnt_userns to the inode set/remove xattr hooks so that the GID of the inode on an idmapped mount is correctly determined by posix_acl_update_mode(). Signed-off-by: Roberto Sassu Reviewed-by: Christian Brauner Cc: Andreas Gruenbacher Signed-off-by: Mimi Zohar

evm: Allow xattr/attr operations for portable signatures

2021-05-21T16:48:39Z

If files with portable signatures are copied from one location to another or are extracted from an archive, verification can temporarily fail until all xattrs/attrs are set in the destination. Only portable signatures may be moved or copied from one file to another, as they don't depend on system-specific information such as the inode generation. Instead portable signatures must include security.ima. Unlike other security.evm types, EVM portable signatures are also immutable. Thus, it wouldn't be a problem to allow xattr/attr operations when verification fails, as portable signatures will never be replaced with the HMAC on possibly corrupted xattrs/attrs. This patch first introduces a new integrity status called INTEGRITY_FAIL_IMMUTABLE, that allows callers of evm_verify_current_integrity() to detect that a portable signature didn't pass verification and then adds an exception in evm_protect_xattr() and evm_inode_setattr() for this status and returns 0 instead of -EPERM. Signed-off-by: Roberto Sassu Signed-off-by: Mimi Zohar

evm: Introduce evm_hmac_disabled() to safely ignore verification errors

2021-05-21T16:48:30Z

When a file is being created, LSMs can set the initial label with the inode_init_security hook. If no HMAC key is loaded, the new file will have LSM xattrs but not the HMAC. It is also possible that the file remains without protected xattrs after creation if no active LSM provided it, or because the filesystem does not support them. Unfortunately, EVM will deny any further metadata operation on new files, as evm_protect_xattr() will return the INTEGRITY_NOLABEL error if protected xattrs exist without security.evm, INTEGRITY_NOXATTRS if no protected xattrs exist or INTEGRITY_UNKNOWN if xattrs are not supported. This would limit the usability of EVM when only a public key is loaded, as commands such as cp or tar with the option to preserve xattrs won't work. This patch introduces the evm_hmac_disabled() function to determine whether or not it is safe to ignore verification errors, based on the ability of EVM to calculate HMACs. If the HMAC key is not loaded, and it cannot be loaded in the future due to the EVM_SETUP_COMPLETE initialization flag, allowing an operation despite the attrs/xattrs being found invalid will not make them valid. Since the post hooks can be executed even when the HMAC key is not loaded, this patch also ensures that the EVM_INIT_HMAC initialization flag is set before the post hooks call evm_update_evmxattr(). Signed-off-by: Roberto Sassu Suggested-by: Mimi Zohar (for ensuring EVM_INIT_HMAC is set) Signed-off-by: Mimi Zohar