kernel/linux.git/security/integrity/ima/ima_init.c, branch v6.6.131

ima: define ima_max_digest_data struct without a flexible array variable

2022-02-15T16:52:06+00:00

To support larger hash digests in the 'iint' cache, instead of defining the 'digest' field as the maximum digest size, the 'digest' field was defined as a flexible array variable. The "ima_digest_data" struct was wrapped inside a local structure with the maximum digest size. But before adding the record to the iint cache, memory for the exact digest size was dynamically allocated. The original reason for defining the 'digest' field as a flexible array variable is still valid for the 'iint' cache use case. Instead of wrapping the 'ima_digest_data' struct in a local structure define 'ima_max_digest_data' struct. Reviewed-by: Stefan Berger Signed-off-by: Mimi Zohar

ima: Add digest and digest_len params to the functions to measure a buffer

2021-07-23T13:27:02+00:00

This patch performs the final modification necessary to pass the buffer measurement to callers, so that they provide a functionality similar to ima_file_hash(). It adds the 'digest' and 'digest_len' parameters to ima_measure_critical_data() and process_buffer_measurement(). These functions calculate the digest even if there is no suitable rule in the IMA policy and, in this case, they simply return 1 before generating a new measurement entry. Signed-off-by: Roberto Sassu Reviewed-by: Lakshmi Ramasubramanian Signed-off-by: Mimi Zohar

evm: Load EVM key in ima_load_x509() to avoid appraisal

2021-05-21T16:47:04+00:00

The public builtin keys do not need to be appraised by IMA as the restriction on the IMA/EVM trusted keyrings ensures that a key can be loaded only if it is signed with a key on the builtin or secondary keyrings. However, when evm_load_x509() is called, appraisal is already enabled and a valid IMA signature must be added to the EVM key to pass verification. Since the restriction is applied on both IMA and EVM trusted keyrings, it is safe to disable appraisal also when the EVM key is loaded. This patch calls evm_load_x509() inside ima_load_x509() if CONFIG_IMA_LOAD_X509 is enabled, which crosses the normal IMA and EVM boundary. Signed-off-by: Roberto Sassu Signed-off-by: Mimi Zohar

IMA: Measure kernel version in early boot

2021-01-27T00:06:41+00:00

The integrity of a kernel can be verified by the boot loader on cold boot, and during kexec, by the current running kernel, before it is loaded. However, it is still possible that the new kernel being loaded is older than the current kernel, and/or has known vulnerabilities. Therefore, it is imperative that an attestation service be able to verify the version of the kernel being loaded on the client, from cold boot and subsequent kexec system calls, ensuring that only kernels with versions known to be good are loaded. Measure the kernel version using ima_measure_critical_data() early on in the boot sequence, reducing the chances of known kernel vulnerabilities being exploited. With IMA being part of the kernel, this overall approach makes the measurement itself more trustworthy. To enable measuring the kernel version "ima_policy=critical_data" needs to be added to the kernel command line arguments. For example, BOOT_IMAGE=/boot/vmlinuz-5.11.0-rc3+ root=UUID=fd643309-a5d2-4ed3-b10d-3c579a5fab2f ro nomodeset ima_policy=critical_data If runtime measurement of the kernel version is ever needed, the following should be added to /etc/ima/ima-policy: measure func=CRITICAL_DATA label=kernel_info To extract the measured data after boot, the following command can be used: grep -m 1 "kernel_version" \ /sys/kernel/security/integrity/ima/ascii_runtime_measurements Sample output from the command above: 10 a8297d408e9d5155728b619761d0dd4cedf5ef5f ima-buf sha256:5660e19945be0119bc19cbbf8d9c33a09935ab5d30dad48aa11f879c67d70988 kernel_version 352e31312e302d7263332d31363138372d676564623634666537383234342d6469727479 The above hex-ascii string corresponds to the kernel version (e.g. xxd -r -p): 5.11.0-rc3-16187-gedb64fe78244-dirty Signed-off-by: Raphael Gianotti Signed-off-by: Mimi Zohar

ima: Call ima_calc_boot_aggregate() in ima_eventdigest_init()

2020-06-03T21:20:43+00:00

If the template field 'd' is chosen and the digest to be added to the measurement entry was not calculated with SHA1 or MD5, it is recalculated with SHA1, by using the passed file descriptor. However, this cannot be done for boot_aggregate, because there is no file descriptor. This patch adds a call to ima_calc_boot_aggregate() in ima_eventdigest_init(), so that the digest can be recalculated also for the boot_aggregate entry. Cc: stable@vger.kernel.org # 3.13.x Fixes: 3ce1217d6cd5d ("ima: define template fields library and new helpers") Reported-by: Takashi Iwai Signed-off-by: Roberto Sassu Signed-off-by: Mimi Zohar

ima: Switch to ima_hash_algo for boot aggregate

2020-04-20T02:03:39+00:00

boot_aggregate is the first entry of IMA measurement list. Its purpose is to link pre-boot measurements to IMA measurements. As IMA was designed to work with a TPM 1.2, the SHA1 PCR bank was always selected even if a TPM 2.0 with support for stronger hash algorithms is available. This patch first tries to find a PCR bank with the IMA default hash algorithm. If it does not find it, it selects the SHA256 PCR bank for TPM 2.0 and SHA1 for TPM 1.2. Ultimately, it selects SHA1 also for TPM 2.0 if the SHA256 PCR bank is not found. If none of the PCR banks above can be found, boot_aggregate file digest is filled with zeros, as for TPM bypass, making it impossible to perform a remote attestation of the system. Cc: stable@vger.kernel.org # 5.1.x Fixes: 879b589210a9 ("tpm: retrieve digest size of unknown algorithms with PCR read") Reported-by: Jerry Snitselaar Suggested-by: James Bottomley Signed-off-by: Roberto Sassu Signed-off-by: Mimi Zohar

integrity: Remove duplicate pr_fmt definitions

2020-02-28T19:32:58+00:00

The #define for formatting log messages, pr_fmt, is duplicated in the files under security/integrity. This change moves the definition to security/integrity/integrity.h and removes the duplicate definitions in the other files under security/integrity. With this change, the messages in the following files will be prefixed with 'integrity'. security/integrity/platform_certs/platform_keyring.c security/integrity/platform_certs/load_powerpc.c security/integrity/platform_certs/load_uefi.c security/integrity/iint.c e.g. "integrity: Error adding keys to platform keyring %s\n" And the messages in the following file will be prefixed with 'ima'. security/integrity/ima/ima_mok.c e.g. "ima: Allocating IMA blacklist keyring.\n" For the rest of the files under security/integrity, there will be no change in the message format. Suggested-by: Shuah Khan Suggested-by: Joe Perches Signed-off-by: Tushar Sugandhi Reviewed-by: Lakshmi Ramasubramanian Signed-off-by: Mimi Zohar

IMA: Defined delayed workqueue to free the queued keys

2020-01-23T12:37:31+00:00

Keys queued for measurement should be freed if a custom IMA policy was not loaded. Otherwise, the keys will remain queued forever consuming kernel memory. This patch defines a delayed workqueue to handle the above scenario. The workqueue handler is setup to execute 5 minutes after IMA initialization is completed. If a custom IMA policy is loaded before the workqueue handler is scheduled to execute, the workqueue task is cancelled and any queued keys are processed for measurement. But if a custom policy was not loaded then the queued keys are just freed when the delayed workqueue handler is run. Signed-off-by: Lakshmi Ramasubramanian Reported-by: kernel test robot # sleeping function called from invalid context Reported-by: kbuild test robot # redefinition of ima_init_key_queue() function. Signed-off-by: Mimi Zohar

Merge branch 'next-integrity' of git://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity

2019-07-09T03:28:59+00:00

Pull integrity updates from Mimi Zohar: "Bug fixes, code clean up, and new features: - IMA policy rules can be defined in terms of LSM labels, making the IMA policy dependent on LSM policy label changes, in particular LSM label deletions. The new environment, in which IMA-appraisal is being used, frequently updates the LSM policy and permits LSM label deletions. - Prevent an mmap'ed shared file opened for write from also being mmap'ed execute. In the long term, making this and other similar changes at the VFS layer would be preferable. - The IMA per policy rule template format support is needed for a couple of new/proposed features (eg. kexec boot command line measurement, appended signatures, and VFS provided file hashes). - Other than the "boot-aggregate" record in the IMA measuremeent list, all other measurements are of file data. Measuring and storing the kexec boot command line in the IMA measurement list is the first buffer based measurement included in the measurement list" * 'next-integrity' of git://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity: integrity: Introduce struct evm_xattr ima: Update MAX_TEMPLATE_NAME_LEN to fit largest reasonable definition KEXEC: Call ima_kexec_cmdline to measure the boot command line args IMA: Define a new template field buf IMA: Define a new hook to measure the kexec boot command line arguments IMA: support for per policy rule template formats integrity: Fix __integrity_init_keyring() section mismatch ima: Use designated initializers for struct ima_event_data ima: use the lsm policy update notifier LSM: switch to blocking policy update notifiers x86/ima: fix the Kconfig dependency for IMA_ARCH_POLICY ima: Make arch_policy_entry static ima: prevent a file already mmap'ed write to be mmap'ed execute x86/ima: check EFI SetupMode too

IMA: support for per policy rule template formats

2019-06-19T22:51:01+00:00

Admins may wish to log different measurements using different IMA templates. Add support for overriding the default template on a per-rule basis. Inspired-by: Roberto Sassu Signed-off-by: Matthew Garrett Signed-off-by: Mimi Zohar