* Re: [PATCH v4] certs: Add EFI_CERT_X509_GUID support for dbx entries [not found] ` <3063834.1611747971@warthog.procyon.org.uk> @ 2021-01-27 14:03 ` Mimi Zohar 2021-01-27 15:41 ` Eric Snowberg 2021-01-29 23:27 ` Jarkko Sakkinen 0 siblings, 2 replies; 5+ messages in thread From: Mimi Zohar @ 2021-01-27 14:03 UTC (permalink / raw) To: David Howells, Jarkko Sakkinen, linux-integrity Cc: Eric Snowberg, Jarkko Sakkinen, dwmw2, herbert, davem, jmorris, serge, nayna, erichte, mpe, keyrings, linux-kernel, linux-crypto, linux-security-module, James.Bottomley [Cc'ing linux-integrity] On Wed, 2021-01-27 at 11:46 +0000, David Howells wrote: > Jarkko Sakkinen <jarkko@kernel.org> wrote: > > > > I suppose a user space tool could be created. But wouldn’t what is > > > currently done in the kernel in this area need to be removed? > > > > Right. I don't think this was a great idea in the first place to > > do to the kernel but since it exists, I guess the patch does make > > sense. > > This information needs to be loaded from the UEFI tables before the system > starts loading any kernel modules or running any programs (if we do > verification of such, which I think IMA can do). There needs to a clear distinction between the pre-boot and post-boot keys. UEFI has its own trust model, which should be limited to UEFI. The .platform keyring was upstreamed and limited to verifying the kexec kernel image. Any other usage of the .platform keyring keys is abusing its intended purpose. The cover letter says, "Anytime the .platform keyring is used, the keys in the .blacklist keyring are referenced, if a matching key is found, the key will be rejected." I don't have a problem with loading the UEFI X509 dbx entries as long as its usage is limited to verifying the kexec kernel image. Mimi ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH v4] certs: Add EFI_CERT_X509_GUID support for dbx entries 2021-01-27 14:03 ` [PATCH v4] certs: Add EFI_CERT_X509_GUID support for dbx entries Mimi Zohar @ 2021-01-27 15:41 ` Eric Snowberg 2021-01-28 4:13 ` Nayna 2021-01-30 10:24 ` Jarkko Sakkinen 2021-01-29 23:27 ` Jarkko Sakkinen 1 sibling, 2 replies; 5+ messages in thread From: Eric Snowberg @ 2021-01-27 15:41 UTC (permalink / raw) To: Mimi Zohar, David Howells, Jarkko Sakkinen Cc: linux-integrity, Jarkko Sakkinen, dwmw2, herbert, davem, jmorris, serge, nayna, erichte, mpe, keyrings, linux-kernel, linux-crypto, linux-security-module, James.Bottomley, Eric Snowberg > On Jan 27, 2021, at 7:03 AM, Mimi Zohar <zohar@linux.ibm.com> wrote: > > [Cc'ing linux-integrity] > > On Wed, 2021-01-27 at 11:46 +0000, David Howells wrote: >> Jarkko Sakkinen <jarkko@kernel.org> wrote: >> >>>> I suppose a user space tool could be created. But wouldn’t what is >>>> currently done in the kernel in this area need to be removed? >>> >>> Right. I don't think this was a great idea in the first place to >>> do to the kernel but since it exists, I guess the patch does make >>> sense. >> >> This information needs to be loaded from the UEFI tables before the system >> starts loading any kernel modules or running any programs (if we do >> verification of such, which I think IMA can do). > > There needs to a clear distinction between the pre-boot and post-boot > keys. UEFI has its own trust model, which should be limited to UEFI. > The .platform keyring was upstreamed and limited to verifying the kexec > kernel image. Any other usage of the .platform keyring keys is > abusing its intended purpose. > > The cover letter says, "Anytime the .platform keyring is used, the > keys in the .blacklist keyring are referenced, if a matching key is > found, the key will be rejected." I don't have a problem with loading > the UEFI X509 dbx entries as long as its usage is limited to verifying > the kexec kernel image. Correct, with my patch, when EFI_CERT_X509_GUID entries are found in the dbx, they will only be used during kexec. I believe the latest dbx file on uefi.org contains three of these entires. Based on my understanding of why the platform keyring was introduced, I intentionally only used these for kexec. I do question the current upstream mainline code though. Currently, when EFI_CERT_X509_SHA256_GUID or EFI_CERT_SHA256_GUID entries are found in the dbx, they are applied everywhere. It seems like there should be a dbx revocation keyring equivalent to the current platform keyring that is only used for pre-boot. If that is a direction you would like to see this go in the future, let me know, I’d be happy to work on it. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH v4] certs: Add EFI_CERT_X509_GUID support for dbx entries 2021-01-27 15:41 ` Eric Snowberg @ 2021-01-28 4:13 ` Nayna 2021-01-30 10:24 ` Jarkko Sakkinen 1 sibling, 0 replies; 5+ messages in thread From: Nayna @ 2021-01-28 4:13 UTC (permalink / raw) To: Eric Snowberg, Mimi Zohar, David Howells, Jarkko Sakkinen Cc: linux-integrity, Jarkko Sakkinen, dwmw2, herbert, davem, jmorris, serge, nayna, erichte, mpe, keyrings, linux-kernel, linux-crypto, linux-security-module, James.Bottomley On 1/27/21 10:41 AM, Eric Snowberg wrote: >> On Jan 27, 2021, at 7:03 AM, Mimi Zohar <zohar@linux.ibm.com> wrote: >> >> [Cc'ing linux-integrity] >> >> On Wed, 2021-01-27 at 11:46 +0000, David Howells wrote: >>> Jarkko Sakkinen <jarkko@kernel.org> wrote: >>> >>>>> I suppose a user space tool could be created. But wouldn’t what is >>>>> currently done in the kernel in this area need to be removed? >>>> Right. I don't think this was a great idea in the first place to >>>> do to the kernel but since it exists, I guess the patch does make >>>> sense. >>> This information needs to be loaded from the UEFI tables before the system >>> starts loading any kernel modules or running any programs (if we do >>> verification of such, which I think IMA can do). >> There needs to a clear distinction between the pre-boot and post-boot >> keys. UEFI has its own trust model, which should be limited to UEFI. >> The .platform keyring was upstreamed and limited to verifying the kexec >> kernel image. Any other usage of the .platform keyring keys is >> abusing its intended purpose. >> >> The cover letter says, "Anytime the .platform keyring is used, the >> keys in the .blacklist keyring are referenced, if a matching key is >> found, the key will be rejected." I don't have a problem with loading >> the UEFI X509 dbx entries as long as its usage is limited to verifying >> the kexec kernel image. > Correct, with my patch, when EFI_CERT_X509_GUID entries are found in the > dbx, they will only be used during kexec. I believe the latest dbx file on > uefi.org contains three of these entires. > > Based on my understanding of why the platform keyring was introduced, > I intentionally only used these for kexec. I do question the current > upstream mainline code though. Currently, when EFI_CERT_X509_SHA256_GUID > or EFI_CERT_SHA256_GUID entries are found in the dbx, they are applied > everywhere. It seems like there should be a dbx revocation keyring > equivalent to the current platform keyring that is only used for pre-boot. > > If that is a direction you would like to see this go in the future, let > me know, I’d be happy to work on it. > Yes, as you said, currently blacklist entries from dbx for EFI_CERT_X509_SHA256_GUID or EFI_CERT_SHA256_GUID are applied everywhere, and does not satisfy the trust model for .platform keyring. We should fix this, but changing now might break some existing systems. Probably it should be discussed as separate thread from this patchset. Thanks & Regards, - Nayna ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH v4] certs: Add EFI_CERT_X509_GUID support for dbx entries 2021-01-27 15:41 ` Eric Snowberg 2021-01-28 4:13 ` Nayna @ 2021-01-30 10:24 ` Jarkko Sakkinen 1 sibling, 0 replies; 5+ messages in thread From: Jarkko Sakkinen @ 2021-01-30 10:24 UTC (permalink / raw) To: Eric Snowberg Cc: Mimi Zohar, David Howells, linux-integrity, Jarkko Sakkinen, dwmw2, herbert, davem, jmorris, serge, nayna, erichte, mpe, keyrings, linux-kernel, linux-crypto, linux-security-module, James.Bottomley On Wed, Jan 27, 2021 at 08:41:29AM -0700, Eric Snowberg wrote: > > > On Jan 27, 2021, at 7:03 AM, Mimi Zohar <zohar@linux.ibm.com> wrote: > > > > [Cc'ing linux-integrity] > > > > On Wed, 2021-01-27 at 11:46 +0000, David Howells wrote: > >> Jarkko Sakkinen <jarkko@kernel.org> wrote: > >> > >>>> I suppose a user space tool could be created. But wouldn’t what is > >>>> currently done in the kernel in this area need to be removed? > >>> > >>> Right. I don't think this was a great idea in the first place to > >>> do to the kernel but since it exists, I guess the patch does make > >>> sense. > >> > >> This information needs to be loaded from the UEFI tables before the system > >> starts loading any kernel modules or running any programs (if we do > >> verification of such, which I think IMA can do). > > > > There needs to a clear distinction between the pre-boot and post-boot > > keys. UEFI has its own trust model, which should be limited to UEFI. > > The .platform keyring was upstreamed and limited to verifying the kexec > > kernel image. Any other usage of the .platform keyring keys is > > abusing its intended purpose. > > > > The cover letter says, "Anytime the .platform keyring is used, the > > keys in the .blacklist keyring are referenced, if a matching key is > > found, the key will be rejected." I don't have a problem with loading > > the UEFI X509 dbx entries as long as its usage is limited to verifying > > the kexec kernel image. > > Correct, with my patch, when EFI_CERT_X509_GUID entries are found in the > dbx, they will only be used during kexec. I believe the latest dbx file on > uefi.org contains three of these entires. > > Based on my understanding of why the platform keyring was introduced, > I intentionally only used these for kexec. I do question the current > upstream mainline code though. Currently, when EFI_CERT_X509_SHA256_GUID > or EFI_CERT_SHA256_GUID entries are found in the dbx, they are applied > everywhere. It seems like there should be a dbx revocation keyring > equivalent to the current platform keyring that is only used for pre-boot. > > If that is a direction you would like to see this go in the future, let > me know, I’d be happy to work on it. I would tend to agree with this. /Jarkko ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH v4] certs: Add EFI_CERT_X509_GUID support for dbx entries 2021-01-27 14:03 ` [PATCH v4] certs: Add EFI_CERT_X509_GUID support for dbx entries Mimi Zohar 2021-01-27 15:41 ` Eric Snowberg @ 2021-01-29 23:27 ` Jarkko Sakkinen 1 sibling, 0 replies; 5+ messages in thread From: Jarkko Sakkinen @ 2021-01-29 23:27 UTC (permalink / raw) To: Mimi Zohar Cc: David Howells, linux-integrity, Eric Snowberg, Jarkko Sakkinen, dwmw2, herbert, davem, jmorris, serge, nayna, erichte, mpe, keyrings, linux-kernel, linux-crypto, linux-security-module, James.Bottomley On Wed, Jan 27, 2021 at 09:03:59AM -0500, Mimi Zohar wrote: > [Cc'ing linux-integrity] > > On Wed, 2021-01-27 at 11:46 +0000, David Howells wrote: > > Jarkko Sakkinen <jarkko@kernel.org> wrote: > > > > > > I suppose a user space tool could be created. But wouldn’t what is > > > > currently done in the kernel in this area need to be removed? > > > > > > Right. I don't think this was a great idea in the first place to > > > do to the kernel but since it exists, I guess the patch does make > > > sense. > > > > This information needs to be loaded from the UEFI tables before the system > > starts loading any kernel modules or running any programs (if we do > > verification of such, which I think IMA can do). > > There needs to a clear distinction between the pre-boot and post-boot > keys. UEFI has its own trust model, which should be limited to UEFI. > The .platform keyring was upstreamed and limited to verifying the kexec > kernel image. Any other usage of the .platform keyring keys is > abusing its intended purpose. > > The cover letter says, "Anytime the .platform keyring is used, the > keys in the .blacklist keyring are referenced, if a matching key is > found, the key will be rejected." I don't have a problem with loading > the UEFI X509 dbx entries as long as its usage is limited to verifying > the kexec kernel image. > > Mimi Thanks Mimi, this is a valid argument. I agree. /Jarkko ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2021-01-30 10:26 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <YAjMm9Gq/FFOzQYG@kernel.org> [not found] ` <E090372C-06A3-4991-8FC3-F06A0DA60729@oracle.com> [not found] ` <20200916004927.64276-1-eric.snowberg@oracle.com> [not found] ` <1360578.1607593748@warthog.procyon.org.uk> [not found] ` <2442460.1610463459@warthog.procyon.org.uk> [not found] ` <X/9a8naM8p4tT5sO@linux.intel.com> [not found] ` <A05E3573-B1AF-474B-94A5-779E69E5880A@oracle.com> [not found] ` <YAFdNiYZSWpB9vOw@kernel.org> [not found] ` <CFBF6AEC-2832-44F7-9D7F-F20489498C33@oracle.com> [not found] ` <YAgTawk3EENF/P6j@kernel.org> [not found] ` <D9F5E0BD-E2FC-428F-91B3-35D2750493A0@oracle.com> [not found] ` <3063834.1611747971@warthog.procyon.org.uk> 2021-01-27 14:03 ` [PATCH v4] certs: Add EFI_CERT_X509_GUID support for dbx entries Mimi Zohar 2021-01-27 15:41 ` Eric Snowberg 2021-01-28 4:13 ` Nayna 2021-01-30 10:24 ` Jarkko Sakkinen 2021-01-29 23:27 ` Jarkko Sakkinen
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).