integrity: eliminate unnecessary "Problem loading X.509 certificate" msg

Currently when the kernel fails to add a cert to the .machine keyring,
it will throw an error immediately in the function int

integrity: eliminate unnecessary "Problem loading X.509 certificate" msg

Currently when the kernel fails to add a cert to the .machine keyring,
it will throw an error immediately in the function integrity_add_key.

Since the kernel will try adding to the .platform keyring next or throw
an error (in the caller of integrity_add_key i.e. add_to_machine_keyring),
so there is no need to throw an error immediately in integrity_add_key.

Reported-by: [email protected]
Closes: https://bugzilla.redhat.com/show_bug.cgi?id=2239331
Fixes: d19967764ba8 ("integrity: Introduce a Linux keyring called machine")
Reviewed-by: Eric Snowberg <[email protected]>
Signed-off-by: Coiby Xu <[email protected]>
Signed-off-by: Mimi Zohar <[email protected]>

show more ...

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 ...

integrity: Enforce digitalSignature usage in the ima and evm keyrings

After being vouched for by a system keyring, only allow keys into the .ima
and .evm keyrings that have the digitalSignature usag

integrity: Enforce digitalSignature usage in the ima and evm keyrings

After being vouched for by a system keyring, only allow keys into the .ima
and .evm keyrings that have the digitalSignature usage field set.

Link: https://lore.kernel.org/all/[email protected]
Suggested-by: Mimi Zohar <[email protected]>
Signed-off-by: Eric Snowberg <[email protected]>
Acked-and-tested-by: Mimi Zohar <[email protected]>
Reviewed-by: Jarkko Sakkinen <[email protected]>
Signed-off-by: Jarkko Sakkinen <[email protected]>

show more ...

integrity: machine keyring CA configuration

Add machine keyring CA restriction options to control the type of
keys that may be added to it. The motivation is separation of
certificate signing from c

integrity: machine keyring CA configuration

Add machine keyring CA restriction options to control the type of
keys that may be added to it. The motivation is separation of
certificate signing from code signing keys. Subsquent work will
limit certificates being loaded into the IMA keyring to code
signing keys used for signature verification.

When no restrictions are selected, all Machine Owner Keys (MOK) are added
to the machine keyring. When CONFIG_INTEGRITY_CA_MACHINE_KEYRING is
selected, the CA bit must be true. Also the key usage must contain
keyCertSign, any other usage field may be set as well.

When CONFIG_INTEGRITY_CA_MACHINE_KEYRING_MAX is selected, the CA bit must
be true. Also the key usage must contain keyCertSign and the
digitialSignature usage may not be set.

Signed-off-by: Eric Snowberg <[email protected]>
Acked-by: Mimi Zohar <[email protected]>
Reviewed-by: Jarkko Sakkinen <[email protected]>
Tested-by: Mimi Zohar <[email protected]>
Signed-off-by: Jarkko Sakkinen <[email protected]>

show more ...

integrity: Fix memory leakage in keyring allocation error path

Key restriction is allocated in integrity_init_keyring(). However, if
keyring allocation failed, it is not freed, causing memory leaks.

integrity: Fix memory leakage in keyring allocation error path

Key restriction is allocated in integrity_init_keyring(). However, if
keyring allocation failed, it is not freed, causing memory leaks.

Fixes: 2b6aa412ff23 ("KEYS: Use structure to capture key restriction function and data")
Signed-off-by: GUO Zihua <[email protected]>
Signed-off-by: Mimi Zohar <[email protected]>

show more ...

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 ...

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 ...

KEYS: store reference to machine keyring

Expose the .machine keyring created in integrity code by adding
a reference. Store a reference to the machine keyring in
system keyring code. The system key

KEYS: store reference to machine keyring

Expose the .machine keyring created in integrity code by adding
a reference. Store a reference to the machine keyring in
system keyring code. The system keyring code needs this to complete
the keyring link to the machine keyring.

Signed-off-by: Eric Snowberg <[email protected]>
Reviewed-by: Jarkko Sakkinen <[email protected]>
Tested-by: Mimi Zohar <[email protected]>
Signed-off-by: Jarkko Sakkinen <[email protected]>

show more ...

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 ...

ima: enable loading of build time generated key on .ima keyring

The kernel currently only loads the kernel module signing key onto the
builtin trusted keyring. Load the module signing key onto the I

ima: enable loading of build time generated key on .ima keyring

The kernel currently only loads the kernel module signing key onto the
builtin trusted keyring. Load the module signing key onto the IMA keyring
as well.

Signed-off-by: Nayna Jain <[email protected]>
Acked-by: Stefan Berger <[email protected]>
Signed-off-by: Mimi Zohar <[email protected]>

show more ...

integrity: Make function integrity_add_key() static

The sparse tool complains as follows:

security/integrity/digsig.c:146:12: warning:
symbol 'integrity_add_key' was not declared. Should it be sta

integrity: Make function integrity_add_key() static

The sparse tool complains as follows:

security/integrity/digsig.c:146:12: warning:
symbol 'integrity_add_key' was not declared. Should it be static?

This function is not used outside of digsig.c, so this
commit marks it static.

Reported-by: Hulk Robot <[email protected]>
Fixes: 60740accf784 ("integrity: Load certs to the platform keyring")
Signed-off-by: Wei Yongjun <[email protected]>
Reviewed-by: Kees Cook <[email protected]>
Reviewed-by: Nayna Jain <[email protected]>
Signed-off-by: Mimi Zohar <[email protected]>

show more ...

fs/kernel_file_read: Add "offset" arg for partial reads

To perform partial reads, callers of kernel_read_file*() must have a
non-NULL file_size argument and a preallocated buffer. The new "offset"
a

fs/kernel_file_read: Add "offset" arg for partial reads

To perform partial reads, callers of kernel_read_file*() must have a
non-NULL file_size argument and a preallocated buffer. The new "offset"
argument can then be used to seek to specific locations in the file to
fill the buffer to, at most, "buf_size" per call.

Where possible, the LSM hooks can report whether a full file has been
read or not so that the contents can be reasoned about.

Signed-off-by: Kees Cook <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

fs/kernel_read_file: Add file_size output argument

In preparation for adding partial read support, add an optional output
argument to kernel_read_file*() that reports the file size so callers
can re

fs/kernel_read_file: Add file_size output argument

In preparation for adding partial read support, add an optional output
argument to kernel_read_file*() that reports the file size so callers
can reason more easily about their reading progress.

Signed-off-by: Kees Cook <[email protected]>
Reviewed-by: Mimi Zohar <[email protected]>
Reviewed-by: Luis Chamberlain <[email protected]>
Reviewed-by: James Morris <[email protected]>
Acked-by: Scott Branden <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

fs/kernel_read_file: Switch buffer size arg to size_t

In preparation for further refactoring of kernel_read_file*(), rename
the "max_size" argument to the more accurate "buf_size", and correct
its t

fs/kernel_read_file: Switch buffer size arg to size_t

In preparation for further refactoring of kernel_read_file*(), rename
the "max_size" argument to the more accurate "buf_size", and correct
its type to size_t. Add kerndoc to explain the specifics of how the
arguments will be used. Note that with buf_size now size_t, it can no
longer be negative (and was never called with a negative value). Adjust
callers to use it as a "maximum size" when *buf is NULL.

Signed-off-by: Kees Cook <[email protected]>
Reviewed-by: Mimi Zohar <[email protected]>
Reviewed-by: Luis Chamberlain <[email protected]>
Reviewed-by: James Morris <[email protected]>
Acked-by: Scott Branden <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

fs/kernel_read_file: Remove redundant size argument

In preparation for refactoring kernel_read_file*(), remove the redundant
"size" argument which is not needed: it can be included in the return
cod

fs/kernel_read_file: Remove redundant size argument

In preparation for refactoring kernel_read_file*(), remove the redundant
"size" argument which is not needed: it can be included in the return
code, with callers adjusted. (VFS reads already cannot be larger than
INT_MAX.)

Signed-off-by: Kees Cook <[email protected]>
Reviewed-by: Mimi Zohar <[email protected]>
Reviewed-by: Luis Chamberlain <[email protected]>
Reviewed-by: James Morris <[email protected]>
Acked-by: Scott Branden <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

fs/kernel_read_file: Split into separate include file

Move kernel_read_file* out of linux/fs.h to its own linux/kernel_read_file.h
include file. That header gets pulled in just about everywhere
and

fs/kernel_read_file: Split into separate include file

Move kernel_read_file* out of linux/fs.h to its own linux/kernel_read_file.h
include file. That header gets pulled in just about everywhere
and doesn't really need functions not related to the general fs interface.

Suggested-by: Christoph Hellwig <[email protected]>
Signed-off-by: Scott Branden <[email protected]>
Signed-off-by: Kees Cook <[email protected]>
Reviewed-by: Christoph Hellwig <[email protected]>
Reviewed-by: Mimi Zohar <[email protected]>
Reviewed-by: Luis Chamberlain <[email protected]>
Acked-by: Greg Kroah-Hartman <[email protected]>
Acked-by: James Morris <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

fs/kernel_read_file: Remove FIRMWARE_PREALLOC_BUFFER enum

FIRMWARE_PREALLOC_BUFFER is a "how", not a "what", and confuses the LSMs
that are interested in filtering between types of things. The "how"

fs/kernel_read_file: Remove FIRMWARE_PREALLOC_BUFFER enum

FIRMWARE_PREALLOC_BUFFER is a "how", not a "what", and confuses the LSMs
that are interested in filtering between types of things. The "how"
should be an internal detail made uninteresting to the LSMs.

Fixes: a098ecd2fa7d ("firmware: support loading into a pre-allocated buffer")
Fixes: fd90bc559bfb ("ima: based on policy verify firmware signatures (pre-allocated buffer)")
Fixes: 4f0496d8ffa3 ("ima: based on policy warn about loading firmware (pre-allocated buffer)")
Signed-off-by: Kees Cook <[email protected]>
Reviewed-by: Mimi Zohar <[email protected]>
Reviewed-by: Luis Chamberlain <[email protected]>
Acked-by: Scott Branden <[email protected]>
Cc: [email protected]
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

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 ...

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 ...

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 ...

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 ...

integrity: Fix __integrity_init_keyring() section mismatch

With gcc-4.6.3:

WARNING: vmlinux.o(.text.unlikely+0x24c64): Section mismatch in reference from the function __integrity_init_keyring()

integrity: Fix __integrity_init_keyring() section mismatch

With gcc-4.6.3:

WARNING: vmlinux.o(.text.unlikely+0x24c64): Section mismatch in reference from the function __integrity_init_keyring() to the function .init.text:set_platform_trusted_keys()
The function __integrity_init_keyring() references
the function __init set_platform_trusted_keys().
This is often because __integrity_init_keyring lacks a __init
annotation or the annotation of set_platform_trusted_keys is wrong.

Indeed, if the compiler decides not to inline __integrity_init_keyring(),
a warning is issued.

Fix this by adding the missing __init annotation.

Fixes: 9dc92c45177ab70e ("integrity: Define a trusted platform keyring")
Signed-off-by: Geert Uytterhoeven <[email protected]>
Reviewed-by: Nayna Jain <[email protected]>
Reviewed-by: James Morris <[email protected]>
Signed-off-by: Mimi Zohar <[email protected]>

show more ...

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 ...

integrity, KEYS: add a reference to platform keyring

commit 9dc92c45177a ("integrity: Define a trusted platform keyring")
introduced a .platform keyring for storing preboot keys, used for
verifying

integrity, KEYS: add a reference to platform keyring

commit 9dc92c45177a ("integrity: Define a trusted platform keyring")
introduced a .platform keyring for storing preboot keys, used for
verifying kernel image signatures. Currently only IMA-appraisal is able
to use the keyring to verify kernel images that have their signature
stored in xattr.

This patch exposes the .platform keyring, making it accessible for
verifying PE signed kernel images as well.

Suggested-by: Mimi Zohar <[email protected]>
Signed-off-by: Kairui Song <[email protected]>
Cc: David Howells <[email protected]>
[[email protected]: fixed checkpatch errors, squashed with patch fix]
Signed-off-by: Mimi Zohar <[email protected]>

show more ...

integrity: Remove references to module keyring

From what I can tell, it has never been used.

Mimi: This was introduced prior to Rusty's decision to use appended
signatures for kernel modules.

Sign

integrity: Remove references to module keyring

From what I can tell, it has never been used.

Mimi: This was introduced prior to Rusty's decision to use appended
signatures for kernel modules.

Signed-off-by: Thiago Jung Bauermann <[email protected]>
Acked-by: Mimi Zohar <[email protected]>
Signed-off-by: James Morris <[email protected]>

show more ...