linux-stable.git/security/integrity, branch linux-5.14.y

IMA: reject unknown hash algorithms in ima_get_hash_algo

2021-11-17T10:04:52+00:00

commit cb181da161963eddc9de0000de6ab2c7942be219 upstream.

The new function validate_hash_algo() assumed that ima_get_hash_algo()
always return a valid 'enum hash_algo', but it returned the
user-supplied value present in the digital signature without
any bounds checks.

Update ima_get_hash_algo() to always return a valid hash algorithm,
defaulting on 'ima_hash_algo' when the user-supplied value inside
the xattr is invalid.

Signed-off-by: THOBY Simon 
Reported-by: syzbot+e8bafe7b82c739eaf153@syzkaller.appspotmail.com
Fixes: 50f742dd9147 ("IMA: block writes of the security.ima xattr with unsupported algorithms")
Reviewed-by: Lakshmi Ramasubramanian 
Signed-off-by: Mimi Zohar 
Signed-off-by: Greg Kroah-Hartman

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

2021-11-17T10:04:05+00:00

[ Upstream commit 50f742dd91474e7f4954bf88d094eede59783883 ]

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 
Signed-off-by: Sasha Levin

evm: mark evm_fixmode as __ro_after_init

2021-11-17T10:03:34+00:00

commit 32ba540f3c2a7ef61ed5a577ce25069a3d714fc9 upstream.

The evm_fixmode is only configurable by command-line option and it is never
modified outside initcalls, so declaring it with __ro_after_init is better.

Signed-off-by: Austin Kim 
Cc: stable@vger.kernel.org
Signed-off-by: Mimi Zohar 
Signed-off-by: Greg Kroah-Hartman

IMA: remove the dependency on CRYPTO_MD5

2021-09-15T08:02:35+00:00

commit 8510505d55e194d3f6c9644c9f9d12c4f6b0395a upstream.

MD5 is a weak digest algorithm that shouldn't be used for cryptographic
operation. It hinders the efficiency of a patch set that aims to limit
the digests allowed for the extended file attribute namely security.ima.
MD5 is no longer a requirement for IMA, nor should it be used there.

The sole place where we still use the MD5 algorithm inside IMA is setting
the ima_hash algorithm to MD5, if the user supplies 'ima_hash=md5'
parameter on the command line.  With commit ab60368ab6a4 ("ima: Fallback
to the builtin hash algorithm"), setting "ima_hash=md5" fails gracefully
when CRYPTO_MD5 is not set:
	ima: Can not allocate md5 (reason: -2)
	ima: Allocating md5 failed, going to use default hash algorithm sha256

Remove the CRYPTO_MD5 dependency for IMA.

Signed-off-by: THOBY Simon 
Reviewed-by: Lakshmi Ramasubramanian 
[zohar@linux.ibm.com: include commit number in patch description for
stable.]
Cc: stable@vger.kernel.org # 4.17
Signed-off-by: Mimi Zohar 
Signed-off-by: Greg Kroah-Hartman

IMA: remove -Wmissing-prototypes warning

2021-09-15T08:02:35+00:00

commit a32ad90426a9c8eb3915eed26e08ce133bd9e0da upstream.

With W=1 build, the compiler throws warning message as below:

   security/integrity/ima/ima_mok.c:24:12: warning:
   no previous prototype for ‘ima_mok_init’ [-Wmissing-prototypes]
       __init int ima_mok_init(void)

Silence the warning by adding static keyword to ima_mok_init().

Signed-off-by: Austin Kim 
Fixes: 41c89b64d718 ("IMA: create machine owner and blacklist keyrings")
Cc: stable@vger.kernel.org
Signed-off-by: Mimi Zohar 
Signed-off-by: Greg Kroah-Hartman

evm: Check xattr size discrepancy between kernel and user

2021-06-21T12:34:21+00:00

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:25+00:00

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: support for duplicate measurement records

2021-06-11T16:54:13+00:00

IMA measures contents of a given file/buffer/critical-data record,
and properly re-measures it on change.  However, IMA does not measure
the duplicate value for a given record, since TPM extend is a very
expensive operation.  For example, if the record changes from value
'v#1' to 'v#2', and then back to 'v#1', IMA will not measure and log
the last change to 'v#1', since the hash of 'v#1' for that record is
already present in the IMA htable.  This limits the ability of an
external attestation service to accurately determine the current state
of the system.  The service would incorrectly conclude that the latest
value of the given record on the system is 'v#2', and act accordingly.

Define and use a new Kconfig option IMA_DISABLE_HTABLE to permit
duplicate records in the IMA measurement list.

In addition to the duplicate measurement records described above,
other duplicate file measurement records may be included in the log,
when CONFIG_IMA_DISABLE_HTABLE is enabled.  For example,
    - i_version is not enabled,
    - i_generation changed,
    - same file present on different filesystems,
    - an inode is evicted from dcache

Signed-off-by: Tushar Sugandhi 
Reviewed-by: Petr Vorel 
[zohar@linux.ibm.com: updated list of duplicate measurement records]
Signed-off-by: Mimi Zohar

ima: Fix warning: no previous prototype for function 'ima_add_kexec_buffer'

2021-06-11T15:27:03+00:00

The function prototype for ima_add_kexec_buffer() is present
in 'linux/ima.h'.  But this header file is not included in
ima_kexec.c where the function is implemented.  This results
in the following compiler warning when "-Wmissing-prototypes" flag
is turned on:

  security/integrity/ima/ima_kexec.c:81:6: warning: no previous prototype
  for function 'ima_add_kexec_buffer' [-Wmissing-prototypes]

Include the header file 'linux/ima.h' in ima_kexec.c to fix
the compiler warning.

Fixes: dce92f6b11c3 (arm64: Enable passing IMA log to next kernel on kexec)
Reported-by: kernel test robot 
Signed-off-by: Lakshmi Ramasubramanian 
Acked-by: Rob Herring 
Signed-off-by: Mimi Zohar

ima: differentiate between EVM failures in the audit log

2021-06-10T20:36:41+00:00

Differentiate between an invalid EVM portable signature failure
from other EVM HMAC/signature failures.

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