|
Revision tags: v6.15, v6.15-rc7, v6.15-rc6, v6.15-rc5, v6.15-rc4, v6.15-rc3, v6.15-rc2, v6.15-rc1, v6.14, v6.14-rc7, v6.14-rc6, v6.14-rc5, v6.14-rc4, v6.14-rc3, v6.14-rc2, v6.14-rc1, v6.13, v6.13-rc7, v6.13-rc6, v6.13-rc5, v6.13-rc4, v6.13-rc3, v6.13-rc2, v6.13-rc1, v6.12, v6.12-rc7, v6.12-rc6, v6.12-rc5, v6.12-rc4, v6.12-rc3, v6.12-rc2, v6.12-rc1, v6.11, v6.11-rc7, v6.11-rc6, v6.11-rc5, v6.11-rc4, v6.11-rc3 |
|
| #
08ae3e5f |
| 08-Aug-2024 |
Gustavo A. R. Silva <[email protected]> |
integrity: Use static_assert() to check struct sizes
Commit 38aa3f5ac6d2 ("integrity: Avoid -Wflex-array-member-not-at-end warnings") introduced tagged `struct evm_ima_xattr_data_hdr` and `struct im
integrity: Use static_assert() to check struct sizes
Commit 38aa3f5ac6d2 ("integrity: Avoid -Wflex-array-member-not-at-end warnings") introduced tagged `struct evm_ima_xattr_data_hdr` and `struct ima_digest_data_hdr`. We want to ensure that when new members need to be added to the flexible structures, they are always included within these tagged structs.
So, we use `static_assert()` to ensure that the memory layout for both the flexible structure and the tagged struct is the same after any changes.
Signed-off-by: Gustavo A. R. Silva <[email protected]> Tested-by: Roberto Sassu <[email protected]> Reviewed-by: Roberto Sassu <[email protected]> Signed-off-by: Mimi Zohar <[email protected]>
show more ...
|
|
Revision tags: v6.11-rc2, v6.11-rc1, v6.10, v6.10-rc7, v6.10-rc6, v6.10-rc5, v6.10-rc4, v6.10-rc3, v6.10-rc2, v6.10-rc1, v6.9, v6.9-rc7, v6.9-rc6, v6.9-rc5, v6.9-rc4, v6.9-rc3 |
|
| #
38aa3f5a |
| 04-Apr-2024 |
Gustavo A. R. Silva <[email protected]> |
integrity: Avoid -Wflex-array-member-not-at-end warnings
-Wflex-array-member-not-at-end is coming in GCC-14, and we are getting ready to enable it globally.
There is currently an object (`hdr)` in
integrity: Avoid -Wflex-array-member-not-at-end warnings
-Wflex-array-member-not-at-end is coming in GCC-14, and we are getting ready to enable it globally.
There is currently an object (`hdr)` in `struct ima_max_digest_data` that contains a flexible structure (`struct ima_digest_data`):
struct ima_max_digest_data { struct ima_digest_data hdr; u8 digest[HASH_MAX_DIGESTSIZE]; } __packed;
So, in order to avoid ending up with a flexible-array member in the middle of a struct, we use the `__struct_group()` helper to separate the flexible array from the rest of the members in the flexible structure:
struct ima_digest_data { __struct_group(ima_digest_data_hdr, hdr, __packed,
... the rest of the members
); u8 digest[]; } __packed;
And similarly for `struct evm_ima_xattr_data`.
With the change described above, we can now declare an object of the type of the tagged `struct ima_digest_data_hdr`, without embedding the flexible array in the middle of another struct:
struct ima_max_digest_data { struct ima_digest_data_hdr hdr; u8 digest[HASH_MAX_DIGESTSIZE]; } __packed;
And similarly for `struct evm_digest` and `struct evm_xattr`.
We also use `container_of()` whenever we need to retrieve a pointer to the flexible structure.
So, with these changes, fix the following warnings:
security/integrity/evm/evm.h:64:32: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end] security/integrity/evm/../integrity.h:40:35: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end] security/integrity/evm/../integrity.h:68:32: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end] security/integrity/ima/../integrity.h:40:35: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end] security/integrity/ima/../integrity.h:68:32: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end] security/integrity/integrity.h:40:35: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end] security/integrity/integrity.h:68:32: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end] security/integrity/platform_certs/../integrity.h:40:35: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end] security/integrity/platform_certs/../integrity.h:68:32: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]
Link: https://github.com/KSPP/linux/issues/202 Signed-off-by: Gustavo A. R. Silva <[email protected]> Signed-off-by: Mimi Zohar <[email protected]>
show more ...
|
|
Revision tags: v6.9-rc2, v6.9-rc1, v6.8, v6.8-rc7, v6.8-rc6, v6.8-rc5 |
|
| #
b6c0dec9 |
| 15-Feb-2024 |
Roberto Sassu <[email protected]> |
integrity: Remove LSM
Since now IMA and EVM use their own integrity metadata, it is safe to remove the 'integrity' LSM, with its management of integrity metadata.
Keep the iint.c file only for load
integrity: Remove LSM
Since now IMA and EVM use their own integrity metadata, it is safe to remove the 'integrity' LSM, with its management of integrity metadata.
Keep the iint.c file only for loading IMA and EVM keys at boot, and for creating the integrity directory in securityfs (we need to keep it for retrocompatibility reasons).
Signed-off-by: Roberto Sassu <[email protected]> Reviewed-by: Casey Schaufler <[email protected]> Reviewed-by: Stefan Berger <[email protected]> Reviewed-by: Mimi Zohar <[email protected]> Acked-by: Mimi Zohar <[email protected]> Signed-off-by: Paul Moore <[email protected]>
show more ...
|
| #
4de2f084 |
| 15-Feb-2024 |
Roberto Sassu <[email protected]> |
ima: Make it independent from 'integrity' LSM
Make the 'ima' LSM independent from the 'integrity' LSM by introducing IMA own integrity metadata (ima_iint_cache structure, with IMA-specific fields fr
ima: Make it independent from 'integrity' LSM
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 <[email protected]> Reviewed-by: Casey Schaufler <[email protected]> Reviewed-by: Stefan Berger <[email protected]> Reviewed-by: Mimi Zohar <[email protected]> Acked-by: Mimi Zohar <[email protected]> Signed-off-by: Paul Moore <[email protected]>
show more ...
|
| #
75a323e6 |
| 15-Feb-2024 |
Roberto Sassu <[email protected]> |
evm: Make it independent from 'integrity' LSM
Define a new structure for EVM-specific metadata, called evm_iint_cache, and embed it in the inode security blob. Introduce evm_iint_inode() to retrieve
evm: Make it independent from 'integrity' LSM
Define a new structure for EVM-specific metadata, called evm_iint_cache, and embed it in the inode security blob. Introduce evm_iint_inode() to retrieve metadata, and register evm_inode_alloc_security() for the inode_alloc_security LSM hook, to initialize the structure (before splitting metadata, this task was done by iint_init_always()).
Keep the non-NULL checks after calling evm_iint_inode() except in evm_inode_alloc_security(), to take into account inodes for which security_inode_alloc() was not called. When using shared metadata, obtaining a NULL pointer from integrity_iint_find() meant that the file wasn't in the IMA policy. Now, because IMA and EVM use disjoint metadata, the EVM status has to be stored for every inode regardless of the IMA policy.
Given that from now on EVM relies on its own metadata, remove the iint parameter from evm_verifyxattr(). Also, directly retrieve the iint in evm_verify_hmac(), called by both evm_verifyxattr() and evm_verify_current_integrity(), since now there is no performance penalty in retrieving EVM metadata (constant time).
Replicate the management of the IMA_NEW_FILE flag, by introducing evm_post_path_mknod() and evm_file_release() to respectively set and clear the newly introduced flag EVM_NEW_FILE, at the same time IMA does. Like for IMA, select CONFIG_SECURITY_PATH when EVM is enabled, to ensure that files are marked as new.
Unlike ima_post_path_mknod(), evm_post_path_mknod() cannot check if a file must be appraised. Thus, it marks all affected files. Also, it does not clear EVM_NEW_FILE depending on i_version, but that is not a problem because IMA_NEW_FILE is always cleared when set in ima_check_last_writer().
Move the EVM-specific flag EVM_IMMUTABLE_DIGSIG to security/integrity/evm/evm.h, since that definition is now unnecessary in the common integrity layer.
Finally, switch to the LSM reservation mechanism for the EVM xattr, and consequently decrement by one the number of xattrs to allocate in security_inode_init_security().
Signed-off-by: Roberto Sassu <[email protected]> Reviewed-by: Casey Schaufler <[email protected]> Reviewed-by: Stefan Berger <[email protected]> Reviewed-by: Mimi Zohar <[email protected]> Acked-by: Mimi Zohar <[email protected]> Signed-off-by: Paul Moore <[email protected]>
show more ...
|
| #
cd3cec0a |
| 15-Feb-2024 |
Roberto Sassu <[email protected]> |
ima: Move to LSM infrastructure
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'
ima: Move to LSM infrastructure
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 <[email protected]> Acked-by: Chuck Lever <[email protected]> Acked-by: Casey Schaufler <[email protected]> Acked-by: Christian Brauner <[email protected]> Reviewed-by: Stefan Berger <[email protected]> Reviewed-by: Mimi Zohar <[email protected]> Acked-by: Mimi Zohar <[email protected]> Signed-off-by: Paul Moore <[email protected]>
show more ...
|
|
Revision tags: v6.8-rc4, v6.8-rc3, v6.8-rc2, v6.8-rc1, v6.7, v6.7-rc8, v6.7-rc7, v6.7-rc6, v6.7-rc5, v6.7-rc4, v6.7-rc3, v6.7-rc2, v6.7-rc1, v6.6, v6.6-rc7 |
|
| #
b836c4d2 |
| 18-Oct-2023 |
Mimi Zohar <[email protected]> |
ima: detect changes to the backing overlay file
Commit 18b44bc5a672 ("ovl: Always reevaluate the file signature for IMA") forced signature re-evaulation on every file access.
Instead of always re-e
ima: detect changes to the backing overlay file
Commit 18b44bc5a672 ("ovl: Always reevaluate the file signature for IMA") forced signature re-evaulation on every file access.
Instead of always re-evaluating the file's integrity, detect a change to the backing file, by comparing the cached file metadata with the backing file's metadata. Verifying just the i_version has not changed is insufficient. In addition save and compare the i_ino and s_dev as well.
Reviewed-by: Amir Goldstein <[email protected]> Tested-by: Eric Snowberg <[email protected]> Tested-by: Raul E Rangel <[email protected]> Cc: [email protected] Signed-off-by: Mimi Zohar <[email protected]>
show more ...
|
|
Revision tags: v6.6-rc6, v6.6-rc5, v6.6-rc4, v6.6-rc3, v6.6-rc2, v6.6-rc1, v6.5, v6.5-rc7 |
|
| #
4cb1ed94 |
| 15-Aug-2023 |
Nayna Jain <[email protected]> |
integrity: check whether imputed trust is enabled
trust_moklist() is specific to UEFI enabled systems. Other platforms rely only on the Kconfig.
Define a generic wrapper named imputed_trust_enabled
integrity: check whether imputed trust is enabled
trust_moklist() is specific to UEFI enabled systems. Other platforms rely only on the Kconfig.
Define a generic wrapper named imputed_trust_enabled().
Signed-off-by: Nayna Jain <[email protected]> Reviewed-by: Mimi Zohar <[email protected]> Tested-by: Nageswara R Sastry <[email protected]> Signed-off-by: Jarkko Sakkinen <[email protected]>
show more ...
|
|
Revision tags: v6.5-rc6, v6.5-rc5, v6.5-rc4, v6.5-rc3, v6.5-rc2, v6.5-rc1, v6.4, v6.4-rc7, v6.4-rc6, v6.4-rc5, v6.4-rc4, v6.4-rc3, v6.4-rc2, v6.4-rc1, v6.3, v6.3-rc7, v6.3-rc6, v6.3-rc5, v6.3-rc4, v6.3-rc3, v6.3-rc2, v6.3-rc1, v6.2, v6.2-rc8, v6.2-rc7, v6.2-rc6, v6.2-rc5, v6.2-rc4, v6.2-rc3, v6.2-rc2, v6.2-rc1, v6.1, v6.1-rc8, v6.1-rc7, v6.1-rc6, v6.1-rc5, v6.1-rc4, v6.1-rc3, v6.1-rc2, v6.1-rc1, v6.0, v6.0-rc7, v6.0-rc6, v6.0-rc5, v6.0-rc4, v6.0-rc3, v6.0-rc2, v6.0-rc1, v5.19, v5.19-rc8, v5.19-rc7, v5.19-rc6, v5.19-rc5, v5.19-rc4, v5.19-rc3, v5.19-rc2, v5.19-rc1, v5.18, v5.18-rc7, v5.18-rc6, v5.18-rc5, v5.18-rc4, v5.18-rc3, v5.18-rc2, v5.18-rc1, v5.17, v5.17-rc8, v5.17-rc7, v5.17-rc6, v5.17-rc5, v5.17-rc4, v5.17-rc3, v5.17-rc2, v5.17-rc1, v5.16, v5.16-rc8, v5.16-rc7, v5.16-rc6, v5.16-rc5, v5.16-rc4, v5.16-rc3 |
|
| #
398c42e2 |
| 24-Nov-2021 |
Mimi Zohar <[email protected]> |
ima: support fs-verity file digest based version 3 signatures
IMA may verify a file's integrity against a "good" value stored in the 'security.ima' xattr or as an appended signature, based on policy
ima: support fs-verity file digest based version 3 signatures
IMA may verify a file's integrity against a "good" value stored in the 'security.ima' xattr or as an appended signature, based on policy. When the "good value" is stored in the xattr, the xattr may contain a file hash or signature. In either case, the "good" value is preceded by a header. The first byte of the xattr header indicates the type of data - hash, signature - stored in the xattr. To support storing fs-verity signatures in the 'security.ima' xattr requires further differentiating the fs-verity signature from the existing IMA signature.
In addition the signatures stored in 'security.ima' xattr, need to be disambiguated. Instead of directly signing the fs-verity digest, a new signature format version 3 is defined as the hash of the ima_file_id structure, which identifies the type of signature and the digest.
The IMA policy defines "which" files are to be measured, verified, and/or audited. For those files being verified, the policy rules indicate "how" the file should be verified. For example to require a file be signed, the appraise policy rule must include the 'appraise_type' option.
appraise_type:= [imasig] | [imasig|modsig] | [sigv3] where 'imasig' is the original or signature format v2 (default), where 'modsig' is an appended signature, where 'sigv3' is the signature format v3.
The policy rule must also indicate the type of digest, if not the IMA default, by first specifying the digest type:
digest_type:= [verity]
The following policy rule requires fsverity signatures. The rule may be constrained, for example based on a fsuuid or LSM label.
appraise func=BPRM_CHECK digest_type=verity appraise_type=sigv3
Acked-by: Stefan Berger <[email protected]> Signed-off-by: Mimi Zohar <[email protected]>
show more ...
|
| #
54f03916 |
| 23-Dec-2021 |
Mimi Zohar <[email protected]> |
ima: permit fsverity's file digests in the IMA measurement list
Permit fsverity's file digest (a hash of struct fsverity_descriptor) to be included in the IMA measurement list, based on the new meas
ima: permit fsverity's file digests in the IMA measurement list
Permit fsverity's file digest (a hash of struct fsverity_descriptor) to be included in the IMA measurement list, based on the new measurement policy rule 'digest_type=verity' option.
To differentiate between a regular IMA file hash from an fsverity's file digest, use the new d-ngv2 format field included in the ima-ngv2 template.
The following policy rule requires fsverity file digests and specifies the new 'ima-ngv2' template, which contains the new 'd-ngv2' field. The policy rule may be constrained, for example based on a fsuuid or LSM label.
measure func=FILE_CHECK digest_type=verity template=ima-ngv2
Acked-by: Stefan Berger <[email protected]> Signed-off-by: Mimi Zohar <[email protected]>
show more ...
|
| #
3d6ae1a5 |
| 26-Jan-2022 |
Eric Snowberg <[email protected]> |
integrity: Only use machine keyring when uefi_check_trust_mok_keys is true
With the introduction of uefi_check_trust_mok_keys, it signifies the end- user wants to trust the machine keyring as truste
integrity: Only use machine keyring when uefi_check_trust_mok_keys is true
With the introduction of uefi_check_trust_mok_keys, it signifies the end- user wants to trust the machine keyring as trusted keys. If they have chosen to trust the machine keyring, load the qualifying keys into it during boot, then link it to the secondary keyring . If the user has not chosen to trust the machine keyring, it will be empty and not linked to the secondary keyring.
Signed-off-by: Eric Snowberg <[email protected]> Reviewed-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Jarkko Sakkinen <[email protected]>
show more ...
|
| #
d1996776 |
| 26-Jan-2022 |
Eric Snowberg <[email protected]> |
integrity: Introduce a Linux keyring called machine
Many UEFI Linux distributions boot using shim. The UEFI shim provides what is called Machine Owner Keys (MOK). Shim uses both the UEFI Secure Boo
integrity: Introduce a Linux keyring called machine
Many UEFI Linux distributions boot using shim. The UEFI shim provides what is called Machine Owner Keys (MOK). Shim uses both the UEFI Secure Boot DB and MOK keys to validate the next step in the boot chain. The MOK facility can be used to import user generated keys. These keys can be used to sign an end-users development kernel build. When Linux boots, both UEFI Secure Boot DB and MOK keys get loaded in the Linux .platform keyring.
Define a new Linux keyring called machine. This keyring shall contain just MOK keys and not the remaining keys in the platform keyring. This new machine keyring will be used in follow on patches. Unlike keys in the platform keyring, keys contained in the machine keyring will be trusted within the kernel if the end-user has chosen to do so.
Signed-off-by: Eric Snowberg <[email protected]> Tested-by: Jarkko Sakkinen <[email protected]> Tested-by: Mimi Zohar <[email protected]> Reviewed-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Jarkko Sakkinen <[email protected]>
show more ...
|
| #
8c54135e |
| 24-Jan-2022 |
Mimi Zohar <[email protected]> |
ima: define ima_max_digest_data struct without a flexible array variable
To support larger hash digests in the 'iint' cache, instead of defining the 'digest' field as the maximum digest size, the 'd
ima: define ima_max_digest_data struct without a flexible array variable
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 <[email protected]> Signed-off-by: Mimi Zohar <[email protected]>
show more ...
|
| #
aae6ccbd |
| 28-Dec-2021 |
Mimi Zohar <[email protected]> |
ima: rename IMA_ACTION_FLAGS to IMA_NONACTION_FLAGS
Simple policy rule options, such as fowner, uid, or euid, can be checked immediately, while other policy rule options, such as requiring a file si
ima: rename IMA_ACTION_FLAGS to IMA_NONACTION_FLAGS
Simple policy rule options, such as fowner, uid, or euid, can be checked immediately, while other policy rule options, such as requiring a file signature, need to be deferred.
The 'flags' field in the integrity_iint_cache struct contains the policy action', 'subaction', and non action/subaction.
action: measure/measured, appraise/appraised, (collect)/collected, audit/audited subaction: appraise status for each hook (e.g. file, mmap, bprm, read, creds) non action/subaction: deferred policy rule options and state
Rename the IMA_ACTION_FLAGS to IMA_NONACTION_FLAGS.
Reviewed-by: Stefan Berger <[email protected]> Signed-off-by: Mimi Zohar <[email protected]>
show more ...
|
|
Revision tags: v5.16-rc2, v5.16-rc1, v5.15, v5.15-rc7, v5.15-rc6, v5.15-rc5, v5.15-rc4, v5.15-rc3, v5.15-rc2, v5.15-rc1, v5.14, v5.14-rc7, v5.14-rc6, v5.14-rc5, v5.14-rc4, v5.14-rc3, v5.14-rc2, v5.14-rc1, v5.13, v5.13-rc7, v5.13-rc6, v5.13-rc5, v5.13-rc4, v5.13-rc3, v5.13-rc2, v5.13-rc1, v5.12, v5.12-rc8, v5.12-rc7, v5.12-rc6, v5.12-rc5, v5.12-rc4, v5.12-rc3, v5.12-rc2, v5.12-rc1, v5.12-rc1-dontuse, v5.11, v5.11-rc7, v5.11-rc6, v5.11-rc5, v5.11-rc4, v5.11-rc3, v5.11-rc2, v5.11-rc1, v5.10, v5.10-rc7, v5.10-rc6, v5.10-rc5, v5.10-rc4 |
|
| #
a24d22b2 |
| 13-Nov-2020 |
Eric Biggers <[email protected]> |
crypto: sha - split sha.h into sha1.h and sha2.h
Currently <crypto/sha.h> contains declarations for both SHA-1 and SHA-2, and <crypto/sha3.h> contains declarations for SHA-3.
This organization is i
crypto: sha - split sha.h into sha1.h and sha2.h
Currently <crypto/sha.h> contains declarations for both SHA-1 and SHA-2, and <crypto/sha3.h> contains declarations for SHA-3.
This organization is inconsistent, but more importantly SHA-1 is no longer considered to be cryptographically secure. So to the extent possible, SHA-1 shouldn't be grouped together with any of the other SHA versions, and usage of it should be phased out.
Therefore, split <crypto/sha.h> into two headers <crypto/sha1.h> and <crypto/sha2.h>, and make everyone explicitly specify whether they want the declarations for SHA-1, SHA-2, or both.
This avoids making the SHA-1 declarations visible to files that don't want anything to do with SHA-1. It also prepares for potentially moving sha1.h into a new insecure/ or dangerous/ directory.
Signed-off-by: Eric Biggers <[email protected]> Acked-by: Ard Biesheuvel <[email protected]> Acked-by: Jason A. Donenfeld <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
show more ...
|
|
Revision tags: v5.10-rc3, v5.10-rc2, v5.10-rc1, v5.9, v5.9-rc8, v5.9-rc7, v5.9-rc6, v5.9-rc5, v5.9-rc4, v5.9-rc3, v5.9-rc2, v5.9-rc1, v5.8, v5.8-rc7, v5.8-rc6, v5.8-rc5, v5.8-rc4, v5.8-rc3, v5.8-rc2 |
|
| #
2f845882 |
| 18-Jun-2020 |
Lakshmi Ramasubramanian <[email protected]> |
integrity: Add errno field in audit message
Error code is not included in the audit messages logged by the integrity subsystem.
Define a new function integrity_audit_message() that takes error code
integrity: Add errno field in audit message
Error code is not included in the audit messages logged by the integrity subsystem.
Define a new function integrity_audit_message() that takes error code in the "errno" parameter. Add "errno" field in the audit messages logged by the integrity subsystem and set the value passed in the "errno" parameter.
[ 6.303048] audit: type=1804 audit(1592506281.627:2): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=kernel op=measuring_key cause=ENOMEM comm="swapper/0" name=".builtin_trusted_keys" res=0 errno=-12
[ 7.987647] audit: type=1802 audit(1592506283.312:9): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 op=policy_update cause=completed comm="systemd" res=1 errno=0
[ 8.019432] audit: type=1804 audit(1592506283.344:10): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 op=measuring_kexec_cmdline cause=hashing_error comm="systemd" name="kexec-cmdline" res=0 errno=-22
Signed-off-by: Lakshmi Ramasubramanian <[email protected]> Suggested-by: Steve Grubb <[email protected]> Suggested-by: Mimi Zohar <[email protected]> Signed-off-by: Mimi Zohar <[email protected]>
show more ...
|
|
Revision tags: v5.8-rc1, v5.7 |
|
| #
eb492c62 |
| 28-May-2020 |
Gustavo A. R. Silva <[email protected]> |
ima: Replace zero-length array with flexible-array
There is a regular need in the kernel to provide a way to declare having a dynamically sized set of trailing elements in a structure. Kernel code s
ima: Replace zero-length array with flexible-array
There is a regular need in the kernel to provide a way to declare having a dynamically sized set of trailing elements in a structure. Kernel code should always use “flexible array members”[1] for these cases. The older style of one-element or zero-length arrays should no longer be used[2].
[1] https://en.wikipedia.org/wiki/Flexible_array_member [2] https://github.com/KSPP/linux/issues/21
Signed-off-by: Gustavo A. R. Silva <[email protected]>
show more ...
|
|
Revision tags: v5.7-rc7, v5.7-rc6, v5.7-rc5, v5.7-rc4, v5.7-rc3, v5.7-rc2, v5.7-rc1, v5.6, v5.6-rc7, v5.6-rc6, v5.6-rc5, v5.6-rc4, v5.6-rc3 |
|
| #
555d6d71 |
| 19-Feb-2020 |
Tushar Sugandhi <[email protected]> |
integrity: Remove duplicate pr_fmt definitions
The #define for formatting log messages, pr_fmt, is duplicated in the files under security/integrity.
This change moves the definition to security/int
integrity: Remove duplicate pr_fmt definitions
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 <[email protected]> Suggested-by: Joe Perches <[email protected]> Signed-off-by: Tushar Sugandhi <[email protected]> Reviewed-by: Lakshmi Ramasubramanian <[email protected]> Signed-off-by: Mimi Zohar <[email protected]>
show more ...
|
|
Revision tags: v5.6-rc2, v5.6-rc1, v5.5, v5.5-rc7, v5.5-rc6, v5.5-rc5, v5.5-rc4, v5.5-rc3, v5.5-rc2, v5.5-rc1, v5.4, v5.4-rc8, v5.4-rc7, v5.4-rc6 |
|
| #
273df864 |
| 31-Oct-2019 |
Nayna Jain <[email protected]> |
ima: Check against blacklisted hashes for files with modsig
Asymmetric private keys are used to sign multiple files. The kernel currently supports checking against blacklisted keys. However, if the
ima: Check against blacklisted hashes for files with modsig
Asymmetric private keys are used to sign multiple files. The kernel currently supports checking against blacklisted keys. However, if the public key is blacklisted, any file signed by the blacklisted key will automatically fail signature verification. Blacklisting the public key is not fine enough granularity, as we might want to only blacklist a particular file.
This patch adds support for checking against the blacklisted hash of the file, without the appended signature, based on the IMA policy. It defines a new policy option "appraise_flag=check_blacklist".
In addition to the blacklisted binary hashes stored in the firmware "dbx" variable, the Linux kernel may be configured to load blacklisted binary hashes onto the .blacklist keyring as well. The following example shows how to blacklist a specific kernel module hash.
$ sha256sum kernel/kheaders.ko 77fa889b35a05338ec52e51591c1b89d4c8d1c99a21251d7c22b1a8642a6bad3 kernel/kheaders.ko
$ grep BLACKLIST .config CONFIG_SYSTEM_BLACKLIST_KEYRING=y CONFIG_SYSTEM_BLACKLIST_HASH_LIST="blacklist-hash-list"
$ cat certs/blacklist-hash-list "bin:77fa889b35a05338ec52e51591c1b89d4c8d1c99a21251d7c22b1a8642a6bad3"
Update the IMA custom measurement and appraisal policy rules (/etc/ima-policy):
measure func=MODULE_CHECK template=ima-modsig appraise func=MODULE_CHECK appraise_flag=check_blacklist appraise_type=imasig|modsig
After building, installing, and rebooting the kernel:
545660333 ---lswrv 0 0 \_ blacklist: bin:77fa889b35a05338ec52e51591c1b89d4c8d1c99a21251d7c22b1a8642a6bad3
measure func=MODULE_CHECK template=ima-modsig appraise func=MODULE_CHECK appraise_flag=check_blacklist appraise_type=imasig|modsig
modprobe: ERROR: could not insert 'kheaders': Permission denied
10 0c9834db5a0182c1fb0cdc5d3adcf11a11fd83dd ima-sig sha256:3bc6ed4f0b4d6e31bc1dbc9ef844605abc7afdc6d81a57d77a1ec9407997c40 2 /usr/lib/modules/5.4.0-rc3+/kernel/kernel/kheaders.ko
10 82aad2bcc3fa8ed94762356b5c14838f3bcfa6a0 ima-modsig sha256:3bc6ed4f0b4d6e31bc1dbc9ef844605abc7afdc6d81a57d77a1ec9407997c40 2 /usr/lib/modules/5.4.0rc3+/kernel/kernel/kheaders.ko sha256:77fa889b3 5a05338ec52e51591c1b89d4c8d1c99a21251d7c22b1a8642a6bad3 3082029a06092a864886f70d010702a082028b30820287020101310d300b0609608648 016503040201300b06092a864886f70d01070131820264....
10 25b72217cc1152b44b134ce2cd68f12dfb71acb3 ima-buf sha256:8b58427fedcf8f4b20bc8dc007f2e232bf7285d7b93a66476321f9c2a3aa132 b blacklisted-hash 77fa889b35a05338ec52e51591c1b89d4c8d1c99a21251d7c22b1a8642a6bad3
Signed-off-by: Nayna Jain <[email protected]> [[email protected]: updated patch description] Signed-off-by: Mimi Zohar <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/[email protected]
show more ...
|
|
Revision tags: v5.4-rc5, v5.4-rc4, v5.4-rc3, v5.4-rc2, v5.4-rc1, v5.3, v5.3-rc8, v5.3-rc7, v5.3-rc6, v5.3-rc5, v5.3-rc4, v5.3-rc3, v5.3-rc2, v5.3-rc1, v5.2, v5.2-rc7 |
|
| #
39b07096 |
| 28-Jun-2019 |
Thiago Jung Bauermann <[email protected]> |
ima: Implement support for module-style appended signatures
Implement the appraise_type=imasig|modsig option, allowing IMA to read and verify modsig signatures.
In case a file has both an xattr sig
ima: Implement support for module-style appended signatures
Implement the appraise_type=imasig|modsig option, allowing IMA to read and verify modsig signatures.
In case a file has both an xattr signature and an appended modsig, IMA will only use the appended signature if the key used by the xattr signature isn't present in the IMA or platform keyring.
Because modsig verification needs to convert from an integrity keyring id to the keyring itself, add an integrity_keyring_from_id() function in digsig.c so that integrity_modsig_verify() can use it.
Signed-off-by: Thiago Jung Bauermann <[email protected]> Signed-off-by: Mimi Zohar <[email protected]>
show more ...
|
| #
9044d627 |
| 28-Jun-2019 |
Thiago Jung Bauermann <[email protected]> |
ima: Add modsig appraise_type option for module-style appended signatures
Introduce the modsig keyword to the IMA policy syntax to specify that a given hook should expect the file to have the IMA si
ima: Add modsig appraise_type option for module-style appended signatures
Introduce the modsig keyword to the IMA policy syntax to specify that a given hook should expect the file to have the IMA signature appended to it. Here is how it can be used in a rule:
appraise func=KEXEC_KERNEL_CHECK appraise_type=imasig|modsig
With this rule, IMA will accept either a signature stored in the extended attribute or an appended signature.
For now, the rule above will behave exactly the same as if appraise_type=imasig was specified. The actual modsig implementation will be introduced separately.
Suggested-by: Mimi Zohar <[email protected]> Signed-off-by: Thiago Jung Bauermann <[email protected]> Signed-off-by: Mimi Zohar <[email protected]>
show more ...
|
| #
028db3e2 |
| 11-Jul-2019 |
Linus Torvalds <[email protected]> |
Revert "Merge tag 'keys-acl-20190703' of git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs"
This reverts merge 0f75ef6a9cff49ff612f7ce0578bced9d0b38325 (and thus effectively commits
Revert "Merge tag 'keys-acl-20190703' of git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs"
This reverts merge 0f75ef6a9cff49ff612f7ce0578bced9d0b38325 (and thus effectively commits
7a1ade847596 ("keys: Provide KEYCTL_GRANT_PERMISSION") 2e12256b9a76 ("keys: Replace uid/gid/perm permissions checking with an ACL")
that the merge brought in).
It turns out that it breaks booting with an encrypted volume, and Eric biggers reports that it also breaks the fscrypt tests [1] and loading of in-kernel X.509 certificates [2].
The root cause of all the breakage is likely the same, but David Howells is off email so rather than try to work it out it's getting reverted in order to not impact the rest of the merge window.
[1] https://lore.kernel.org/lkml/[email protected]/ [2] https://lore.kernel.org/lkml/[email protected]/
Link: https://lore.kernel.org/lkml/CAHk-=wjxoeMJfeBahnWH=9zShKp2bsVy527vo3_y8HfOdhwAAw@mail.gmail.com/ Reported-by: Eric Biggers <[email protected]> Cc: David Howells <[email protected]> Cc: James Morris <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
show more ...
|
|
Revision tags: v5.2-rc6, v5.2-rc5 |
|
| #
650b29db |
| 11-Jun-2019 |
Thiago Jung Bauermann <[email protected]> |
integrity: Introduce struct evm_xattr
Even though struct evm_ima_xattr_data includes a fixed-size array to hold a SHA1 digest, most of the code ignores the array and uses the struct to mean "type in
integrity: Introduce struct evm_xattr
Even though struct evm_ima_xattr_data includes a fixed-size array to hold a SHA1 digest, most of the code ignores the array and uses the struct to mean "type indicator followed by data of unspecified size" and tracks the real size of what the struct represents in a separate length variable.
The only exception to that is the EVM code, which correctly uses the definition of struct evm_ima_xattr_data.
So make this explicit in the code by removing the length specification from the array in struct evm_ima_xattr_data. Also, change the name of the element from digest to data since in most places the array doesn't hold a digest.
A separate struct evm_xattr is introduced, with the original definition of evm_ima_xattr_data to be used in the places that actually expect that definition, specifically the EVM HMAC code.
Signed-off-by: Thiago Jung Bauermann <[email protected]> Signed-off-by: Mimi Zohar <[email protected]>
show more ...
|
| #
2e12256b |
| 27-Jun-2019 |
David Howells <[email protected]> |
keys: Replace uid/gid/perm permissions checking with an ACL
Replace the uid/gid/perm permissions checking on a key with an ACL to allow the SETATTR and SEARCH permissions to be split. This will als
keys: Replace uid/gid/perm permissions checking with an ACL
Replace the uid/gid/perm permissions checking on a key with an ACL to allow the SETATTR and SEARCH permissions to be split. This will also allow a greater range of subjects to represented.
============ WHY DO THIS? ============
The problem is that SETATTR and SEARCH cover a slew of actions, not all of which should be grouped together.
For SETATTR, this includes actions that are about controlling access to a key:
(1) Changing a key's ownership.
(2) Changing a key's security information.
(3) Setting a keyring's restriction.
And actions that are about managing a key's lifetime:
(4) Setting an expiry time.
(5) Revoking a key.
and (proposed) managing a key as part of a cache:
(6) Invalidating a key.
Managing a key's lifetime doesn't really have anything to do with controlling access to that key.
Expiry time is awkward since it's more about the lifetime of the content and so, in some ways goes better with WRITE permission. It can, however, be set unconditionally by a process with an appropriate authorisation token for instantiating a key, and can also be set by the key type driver when a key is instantiated, so lumping it with the access-controlling actions is probably okay.
As for SEARCH permission, that currently covers:
(1) Finding keys in a keyring tree during a search.
(2) Permitting keyrings to be joined.
(3) Invalidation.
But these don't really belong together either, since these actions really need to be controlled separately.
Finally, there are number of special cases to do with granting the administrator special rights to invalidate or clear keys that I would like to handle with the ACL rather than key flags and special checks.
=============== WHAT IS CHANGED ===============
The SETATTR permission is split to create two new permissions:
(1) SET_SECURITY - which allows the key's owner, group and ACL to be changed and a restriction to be placed on a keyring.
(2) REVOKE - which allows a key to be revoked.
The SEARCH permission is split to create:
(1) SEARCH - which allows a keyring to be search and a key to be found.
(2) JOIN - which allows a keyring to be joined as a session keyring.
(3) INVAL - which allows a key to be invalidated.
The WRITE permission is also split to create:
(1) WRITE - which allows a key's content to be altered and links to be added, removed and replaced in a keyring.
(2) CLEAR - which allows a keyring to be cleared completely. This is split out to make it possible to give just this to an administrator.
(3) REVOKE - see above.
Keys acquire ACLs which consist of a series of ACEs, and all that apply are unioned together. An ACE specifies a subject, such as:
(*) Possessor - permitted to anyone who 'possesses' a key (*) Owner - permitted to the key owner (*) Group - permitted to the key group (*) Everyone - permitted to everyone
Note that 'Other' has been replaced with 'Everyone' on the assumption that you wouldn't grant a permit to 'Other' that you wouldn't also grant to everyone else.
Further subjects may be made available by later patches.
The ACE also specifies a permissions mask. The set of permissions is now:
VIEW Can view the key metadata READ Can read the key content WRITE Can update/modify the key content SEARCH Can find the key by searching/requesting LINK Can make a link to the key SET_SECURITY Can change owner, ACL, expiry INVAL Can invalidate REVOKE Can revoke JOIN Can join this keyring CLEAR Can clear this keyring
The KEYCTL_SETPERM function is then deprecated.
The KEYCTL_SET_TIMEOUT function then is permitted if SET_SECURITY is set, or if the caller has a valid instantiation auth token.
The KEYCTL_INVALIDATE function then requires INVAL.
The KEYCTL_REVOKE function then requires REVOKE.
The KEYCTL_JOIN_SESSION_KEYRING function then requires JOIN to join an existing keyring.
The JOIN permission is enabled by default for session keyrings and manually created keyrings only.
====================== BACKWARD COMPATIBILITY ======================
To maintain backward compatibility, KEYCTL_SETPERM will translate the permissions mask it is given into a new ACL for a key - unless KEYCTL_SET_ACL has been called on that key, in which case an error will be returned.
It will convert possessor, owner, group and other permissions into separate ACEs, if each portion of the mask is non-zero.
SETATTR permission turns on all of INVAL, REVOKE and SET_SECURITY. WRITE permission turns on WRITE, REVOKE and, if a keyring, CLEAR. JOIN is turned on if a keyring is being altered.
The KEYCTL_DESCRIBE function translates the ACL back into a permissions mask to return depending on possessor, owner, group and everyone ACEs.
It will make the following mappings:
(1) INVAL, JOIN -> SEARCH
(2) SET_SECURITY -> SETATTR
(3) REVOKE -> WRITE if SETATTR isn't already set
(4) CLEAR -> WRITE
Note that the value subsequently returned by KEYCTL_DESCRIBE may not match the value set with KEYCTL_SETATTR.
======= TESTING =======
This passes the keyutils testsuite for all but a couple of tests:
(1) tests/keyctl/dh_compute/badargs: The first wrong-key-type test now returns EOPNOTSUPP rather than ENOKEY as READ permission isn't removed if the type doesn't have ->read(). You still can't actually read the key.
(2) tests/keyctl/permitting/valid: The view-other-permissions test doesn't work as Other has been replaced with Everyone in the ACL.
Signed-off-by: David Howells <[email protected]>
show more ...
|
|
Revision tags: v5.2-rc4, v5.2-rc3 |
|
| #
b886d83c |
| 01-Jun-2019 |
Thomas Gleixner <[email protected]> |
treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 441
Based on 1 normalized pattern(s):
this program is free software you can redistribute it and or modify it under the terms of th
treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 441
Based on 1 normalized pattern(s):
this program is free software you can redistribute it and or modify it under the terms of the gnu general public license as published by the free software foundation version 2 of the license
extracted by the scancode license scanner the SPDX license identifier
GPL-2.0-only
has been chosen to replace the boilerplate/reference in 315 file(s).
Signed-off-by: Thomas Gleixner <[email protected]> Reviewed-by: Allison Randal <[email protected]> Reviewed-by: Armijn Hemel <[email protected]> Cc: [email protected] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
show more ...
|