Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1523721 > unrolled thread

[PATCH 9/9] MODSIGN: Allow the "db" UEFI variable to be suppressed

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  [PATCH 9/9] MODSIGN: Allow the "db" UEFI variable to be suppressed David Howells <dhowells@redhat.com> - 2016-11-16 19:20 +0100
    Re: [PATCH 9/9] MODSIGN: Allow the "db" UEFI variable to be suppressed Ard Biesheuvel <ard.biesheuvel@linaro.org> - 2016-11-21 17:20 +0100
      Re: [PATCH 9/9] MODSIGN: Allow the "db" UEFI variable to be suppressed Josh Boyer <jwboyer@fedoraproject.org> - 2016-11-21 17:30 +0100
        Re: [PATCH 9/9] MODSIGN: Allow the "db" UEFI variable to be suppressed Ard Biesheuvel <ard.biesheuvel@linaro.org> - 2016-11-21 17:50 +0100
          Re: [PATCH 9/9] MODSIGN: Allow the "db" UEFI variable to be suppressed Ard Biesheuvel <ard.biesheuvel@linaro.org> - 2016-11-21 20:10 +0100
            Re: [PATCH 9/9] MODSIGN: Allow the "db" UEFI variable to be  suppressed Peter Jones <pjones@redhat.com> - 2016-11-21 20:20 +0100
              Re: [PATCH 9/9] MODSIGN: Allow the "db" UEFI variable to be suppressed Ard Biesheuvel <ard.biesheuvel@linaro.org> - 2016-11-21 20:40 +0100
          Re: [PATCH 9/9] MODSIGN: Allow the "db" UEFI variable to be  suppressed Peter Jones <pjones@redhat.com> - 2016-11-21 20:10 +0100

#1523721 — [PATCH 9/9] MODSIGN: Allow the "db" UEFI variable to be suppressed

From: Josh Boyer <jwboyer@fedoraproject.org>

If a user tells shim to not use the certs/hashes in the UEFI db variable
for verification purposes, shim will set a UEFI variable called
MokIgnoreDB.  Have the uefi import code look for this and ignore the db
variable if it is found.

Signed-off-by: Josh Boyer <jwboyer@fedoraproject.org>
Signed-off-by: David Howells <dhowells@redhat.com>
---

 certs/load_uefi.c |   44 ++++++++++++++++++++++++++++++++++----------
 1 file changed, 34 insertions(+), 10 deletions(-)

diff --git a/certs/load_uefi.c b/certs/load_uefi.c
index b44e464c3ff4..3d8845986019 100644
--- a/certs/load_uefi.c
+++ b/certs/load_uefi.c
@@ -13,6 +13,26 @@ static __initdata efi_guid_t efi_cert_x509_sha256_guid = EFI_CERT_X509_SHA256_GU
 static __initdata efi_guid_t efi_cert_sha256_guid = EFI_CERT_SHA256_GUID;
 
 /*
+ * Look to see if a UEFI variable called MokIgnoreDB exists and return true if
+ * it does.
+ *
+ * This UEFI variable is set by the shim if a user tells the shim to not use
+ * the certs/hashes in the UEFI db variable for verification purposes.  If it
+ * is set, we should ignore the db variable also and the true return indicates
+ * this.
+ */
+static __init bool uefi_check_ignore_db(void)
+{
+	efi_status_t status;
+	unsigned int db = 0;
+	unsigned long size = sizeof(db);
+	efi_guid_t guid = EFI_SHIM_LOCK_GUID;
+
+	status = efi.get_variable(L"MokIgnoreDB", &guid, NULL, &size, &db);
+	return status == EFI_SUCCESS;
+}
+
+/*
  * Get a certificate list blob from the named EFI variable.
  */
 static __init void *get_cert_list(efi_char16_t *name, efi_guid_t *guid,
@@ -113,7 +133,9 @@ static __init efi_element_handler_t get_handler_for_dbx(const efi_guid_t *sig_ty
 }
 
 /*
- * Load the certs contained in the UEFI databases
+ * Load the certs contained in the UEFI databases into the secondary trusted
+ * keyring and the UEFI blacklisted X.509 cert SHA256 hashes into the blacklist
+ * keyring.
  */
 static int __init load_uefi_certs(void)
 {
@@ -129,15 +151,17 @@ static int __init load_uefi_certs(void)
 	/* Get db, MokListRT, and dbx.  They might not exist, so it isn't
 	 * an error if we can't get them.
 	 */
-	db = get_cert_list(L"db", &secure_var, &dbsize);
-	if (!db) {
-		pr_err("MODSIGN: Couldn't get UEFI db list\n");
-	} else {
-		rc = parse_efi_signature_list("UEFI:db",
-					      db, dbsize, get_handler_for_db);
-		if (rc)
-			pr_err("Couldn't parse db signatures: %d\n", rc);
-		kfree(db);
+	if (!uefi_check_ignore_db()) {
+		db = get_cert_list(L"db", &secure_var, &dbsize);
+		if (!db) {
+			pr_err("MODSIGN: Couldn't get UEFI db list\n");
+		} else {
+			rc = parse_efi_signature_list("UEFI:db",
+						      db, dbsize, get_handler_for_db);
+			if (rc)
+				pr_err("Couldn't parse db signatures: %d\n", rc);
+			kfree(db);
+		}
 	}
 
 	mok = get_cert_list(L"MokListRT", &mok_var, &moksize);

[toc] | [next] | [standalone]

#1526864

On 16 November 2016 at 18:11, David Howells <dhowells@redhat.com> wrote:
> From: Josh Boyer <jwboyer@fedoraproject.org>
>
> If a user tells shim to not use the certs/hashes in the UEFI db variable
> for verification purposes, shim will set a UEFI variable called
> MokIgnoreDB.  Have the uefi import code look for this and ignore the db
> variable if it is found.
>

Similar concern as in the previous patch: it appears to me that you
can DoS a machine by setting MokIgnoreDB if, e.g., its modules are
signed against a cert that resides in db, and shim/mokmanager are not
being used.


> Signed-off-by: Josh Boyer <jwboyer@fedoraproject.org>
> Signed-off-by: David Howells <dhowells@redhat.com>
> ---
>
>  certs/load_uefi.c |   44 ++++++++++++++++++++++++++++++++++----------
>  1 file changed, 34 insertions(+), 10 deletions(-)
>
> diff --git a/certs/load_uefi.c b/certs/load_uefi.c
> index b44e464c3ff4..3d8845986019 100644
> --- a/certs/load_uefi.c
> +++ b/certs/load_uefi.c
> @@ -13,6 +13,26 @@ static __initdata efi_guid_t efi_cert_x509_sha256_guid = EFI_CERT_X509_SHA256_GU
>  static __initdata efi_guid_t efi_cert_sha256_guid = EFI_CERT_SHA256_GUID;
>
>  /*
> + * Look to see if a UEFI variable called MokIgnoreDB exists and return true if
> + * it does.
> + *
> + * This UEFI variable is set by the shim if a user tells the shim to not use
> + * the certs/hashes in the UEFI db variable for verification purposes.  If it
> + * is set, we should ignore the db variable also and the true return indicates
> + * this.
> + */
> +static __init bool uefi_check_ignore_db(void)
> +{
> +       efi_status_t status;
> +       unsigned int db = 0;
> +       unsigned long size = sizeof(db);
> +       efi_guid_t guid = EFI_SHIM_LOCK_GUID;
> +
> +       status = efi.get_variable(L"MokIgnoreDB", &guid, NULL, &size, &db);
> +       return status == EFI_SUCCESS;
> +}
> +
> +/*
>   * Get a certificate list blob from the named EFI variable.
>   */
>  static __init void *get_cert_list(efi_char16_t *name, efi_guid_t *guid,
> @@ -113,7 +133,9 @@ static __init efi_element_handler_t get_handler_for_dbx(const efi_guid_t *sig_ty
>  }
>
>  /*
> - * Load the certs contained in the UEFI databases
> + * Load the certs contained in the UEFI databases into the secondary trusted
> + * keyring and the UEFI blacklisted X.509 cert SHA256 hashes into the blacklist
> + * keyring.
>   */
>  static int __init load_uefi_certs(void)
>  {
> @@ -129,15 +151,17 @@ static int __init load_uefi_certs(void)
>         /* Get db, MokListRT, and dbx.  They might not exist, so it isn't
>          * an error if we can't get them.
>          */
> -       db = get_cert_list(L"db", &secure_var, &dbsize);
> -       if (!db) {
> -               pr_err("MODSIGN: Couldn't get UEFI db list\n");
> -       } else {
> -               rc = parse_efi_signature_list("UEFI:db",
> -                                             db, dbsize, get_handler_for_db);
> -               if (rc)
> -                       pr_err("Couldn't parse db signatures: %d\n", rc);
> -               kfree(db);
> +       if (!uefi_check_ignore_db()) {
> +               db = get_cert_list(L"db", &secure_var, &dbsize);
> +               if (!db) {
> +                       pr_err("MODSIGN: Couldn't get UEFI db list\n");
> +               } else {
> +                       rc = parse_efi_signature_list("UEFI:db",
> +                                                     db, dbsize, get_handler_for_db);
> +                       if (rc)
> +                               pr_err("Couldn't parse db signatures: %d\n", rc);
> +                       kfree(db);
> +               }
>         }
>
>         mok = get_cert_list(L"MokListRT", &mok_var, &moksize);
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-efi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[toc] | [prev] | [next] | [standalone]

#1526870

On Mon, Nov 21, 2016 at 11:18 AM, Ard Biesheuvel
<ard.biesheuvel@linaro.org> wrote:
> On 16 November 2016 at 18:11, David Howells <dhowells@redhat.com> wrote:
>> From: Josh Boyer <jwboyer@fedoraproject.org>
>>
>> If a user tells shim to not use the certs/hashes in the UEFI db variable
>> for verification purposes, shim will set a UEFI variable called
>> MokIgnoreDB.  Have the uefi import code look for this and ignore the db
>> variable if it is found.
>>
>
> Similar concern as in the previous patch: it appears to me that you
> can DoS a machine by setting MokIgnoreDB if, e.g., its modules are
> signed against a cert that resides in db, and shim/mokmanager are not
> being used.

If shim/mokmanager aren't used, then you can't actually modify
MokIgnoreDB.  Again, it requires physical access and a reboot into
mokmanager to actually take effect.

josh


>> Signed-off-by: Josh Boyer <jwboyer@fedoraproject.org>
>> Signed-off-by: David Howells <dhowells@redhat.com>
>> ---
>>
>>  certs/load_uefi.c |   44 ++++++++++++++++++++++++++++++++++----------
>>  1 file changed, 34 insertions(+), 10 deletions(-)
>>
>> diff --git a/certs/load_uefi.c b/certs/load_uefi.c
>> index b44e464c3ff4..3d8845986019 100644
>> --- a/certs/load_uefi.c
>> +++ b/certs/load_uefi.c
>> @@ -13,6 +13,26 @@ static __initdata efi_guid_t efi_cert_x509_sha256_guid = EFI_CERT_X509_SHA256_GU
>>  static __initdata efi_guid_t efi_cert_sha256_guid = EFI_CERT_SHA256_GUID;
>>
>>  /*
>> + * Look to see if a UEFI variable called MokIgnoreDB exists and return true if
>> + * it does.
>> + *
>> + * This UEFI variable is set by the shim if a user tells the shim to not use
>> + * the certs/hashes in the UEFI db variable for verification purposes.  If it
>> + * is set, we should ignore the db variable also and the true return indicates
>> + * this.
>> + */
>> +static __init bool uefi_check_ignore_db(void)
>> +{
>> +       efi_status_t status;
>> +       unsigned int db = 0;
>> +       unsigned long size = sizeof(db);
>> +       efi_guid_t guid = EFI_SHIM_LOCK_GUID;
>> +
>> +       status = efi.get_variable(L"MokIgnoreDB", &guid, NULL, &size, &db);
>> +       return status == EFI_SUCCESS;
>> +}
>> +
>> +/*
>>   * Get a certificate list blob from the named EFI variable.
>>   */
>>  static __init void *get_cert_list(efi_char16_t *name, efi_guid_t *guid,
>> @@ -113,7 +133,9 @@ static __init efi_element_handler_t get_handler_for_dbx(const efi_guid_t *sig_ty
>>  }
>>
>>  /*
>> - * Load the certs contained in the UEFI databases
>> + * Load the certs contained in the UEFI databases into the secondary trusted
>> + * keyring and the UEFI blacklisted X.509 cert SHA256 hashes into the blacklist
>> + * keyring.
>>   */
>>  static int __init load_uefi_certs(void)
>>  {
>> @@ -129,15 +151,17 @@ static int __init load_uefi_certs(void)
>>         /* Get db, MokListRT, and dbx.  They might not exist, so it isn't
>>          * an error if we can't get them.
>>          */
>> -       db = get_cert_list(L"db", &secure_var, &dbsize);
>> -       if (!db) {
>> -               pr_err("MODSIGN: Couldn't get UEFI db list\n");
>> -       } else {
>> -               rc = parse_efi_signature_list("UEFI:db",
>> -                                             db, dbsize, get_handler_for_db);
>> -               if (rc)
>> -                       pr_err("Couldn't parse db signatures: %d\n", rc);
>> -               kfree(db);
>> +       if (!uefi_check_ignore_db()) {
>> +               db = get_cert_list(L"db", &secure_var, &dbsize);
>> +               if (!db) {
>> +                       pr_err("MODSIGN: Couldn't get UEFI db list\n");
>> +               } else {
>> +                       rc = parse_efi_signature_list("UEFI:db",
>> +                                                     db, dbsize, get_handler_for_db);
>> +                       if (rc)
>> +                               pr_err("Couldn't parse db signatures: %d\n", rc);
>> +                       kfree(db);
>> +               }
>>         }
>>
>>         mok = get_cert_list(L"MokListRT", &mok_var, &moksize);
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-efi" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[toc] | [prev] | [next] | [standalone]

#1526897

On 21 November 2016 at 16:26, Josh Boyer <jwboyer@fedoraproject.org> wrote:
> On Mon, Nov 21, 2016 at 11:18 AM, Ard Biesheuvel
> <ard.biesheuvel@linaro.org> wrote:
>> On 16 November 2016 at 18:11, David Howells <dhowells@redhat.com> wrote:
>>> From: Josh Boyer <jwboyer@fedoraproject.org>
>>>
>>> If a user tells shim to not use the certs/hashes in the UEFI db variable
>>> for verification purposes, shim will set a UEFI variable called
>>> MokIgnoreDB.  Have the uefi import code look for this and ignore the db
>>> variable if it is found.
>>>
>>
>> Similar concern as in the previous patch: it appears to me that you
>> can DoS a machine by setting MokIgnoreDB if, e.g., its modules are
>> signed against a cert that resides in db, and shim/mokmanager are not
>> being used.
>
> If shim/mokmanager aren't used, then you can't actually modify
> MokIgnoreDB.  Again, it requires physical access and a reboot into
> mokmanager to actually take effect.
>

This does the trick as well

printf "\x07\x00\x00\x00\x01" >
/sys/firmware/efi/efivars/MokIgnoreDB-605dab50-e046-4300-abb6-3dd810dd8b23

[toc] | [prev] | [next] | [standalone]

#1526985

On 21 November 2016 at 20:05, Peter Jones <pjones@redhat.com> wrote:
> On Mon, Nov 21, 2016 at 04:42:45PM +0000, Ard Biesheuvel wrote:
>> On 21 November 2016 at 16:26, Josh Boyer <jwboyer@fedoraproject.org> wrote:
>> > On Mon, Nov 21, 2016 at 11:18 AM, Ard Biesheuvel
>> > <ard.biesheuvel@linaro.org> wrote:
>> >> On 16 November 2016 at 18:11, David Howells <dhowells@redhat.com> wrote:
>> >>> From: Josh Boyer <jwboyer@fedoraproject.org>
>> >>>
>> >>> If a user tells shim to not use the certs/hashes in the UEFI db variable
>> >>> for verification purposes, shim will set a UEFI variable called
>> >>> MokIgnoreDB.  Have the uefi import code look for this and ignore the db
>> >>> variable if it is found.
>> >>>
>> >>
>> >> Similar concern as in the previous patch: it appears to me that you
>> >> can DoS a machine by setting MokIgnoreDB if, e.g., its modules are
>> >> signed against a cert that resides in db, and shim/mokmanager are not
>> >> being used.
>> >
>> > If shim/mokmanager aren't used, then you can't actually modify
>> > MokIgnoreDB.  Again, it requires physical access and a reboot into
>> > mokmanager to actually take effect.
>> >
>>
>> This does the trick as well
>>
>> printf "\x07\x00\x00\x00\x01" >
>> /sys/firmware/efi/efivars/MokIgnoreDB-605dab50-e046-4300-abb6-3dd810dd8b23
>
> So that really means two things.  First, kernel should only honor any of
> the Mok* variables if they're Boot Services-only variables.  Second, to
> avoid the DoS, shim should create them all as Boot Services-only the
> first time it boots.  That'll prevent them from being created post-boot.
>

All of that assumes you are using shim and mokmanager in the first place.

[toc] | [prev] | [next] | [standalone]

#1526993 — Re: [PATCH 9/9] MODSIGN: Allow the "db" UEFI variable to be suppressed

On Mon, Nov 21, 2016 at 08:06:44PM +0100, Ard Biesheuvel wrote:
> On 21 November 2016 at 20:05, Peter Jones <pjones@redhat.com> wrote:
> > On Mon, Nov 21, 2016 at 04:42:45PM +0000, Ard Biesheuvel wrote:
> >> On 21 November 2016 at 16:26, Josh Boyer <jwboyer@fedoraproject.org> wrote:
> >> > On Mon, Nov 21, 2016 at 11:18 AM, Ard Biesheuvel
> >> > <ard.biesheuvel@linaro.org> wrote:
> >> >> On 16 November 2016 at 18:11, David Howells <dhowells@redhat.com> wrote:
> >> >>> From: Josh Boyer <jwboyer@fedoraproject.org>
> >> >>>
> >> >>> If a user tells shim to not use the certs/hashes in the UEFI db variable
> >> >>> for verification purposes, shim will set a UEFI variable called
> >> >>> MokIgnoreDB.  Have the uefi import code look for this and ignore the db
> >> >>> variable if it is found.
> >> >>>
> >> >>
> >> >> Similar concern as in the previous patch: it appears to me that you
> >> >> can DoS a machine by setting MokIgnoreDB if, e.g., its modules are
> >> >> signed against a cert that resides in db, and shim/mokmanager are not
> >> >> being used.
> >> >
> >> > If shim/mokmanager aren't used, then you can't actually modify
> >> > MokIgnoreDB.  Again, it requires physical access and a reboot into
> >> > mokmanager to actually take effect.
> >> >
> >>
> >> This does the trick as well
> >>
> >> printf "\x07\x00\x00\x00\x01" >
> >> /sys/firmware/efi/efivars/MokIgnoreDB-605dab50-e046-4300-abb6-3dd810dd8b23
> >
> > So that really means two things.  First, kernel should only honor any of
> > the Mok* variables if they're Boot Services-only variables.  Second, to
> > avoid the DoS, shim should create them all as Boot Services-only the
> > first time it boots.  That'll prevent them from being created post-boot.
> >
> 
> All of that assumes you are using shim and mokmanager in the first place.

No, it doesn't.  If you're not using shim, there's no DoS problem,
because what would you be DoSing?  And likewise, if you're not using
Secure Boot at all, you have no guarantee of anything about your boot
environment, starting with the idea that the boot loader isn't hostile.
If you're not using Secure Boot, a hostile pre-boot driver could easily
add DB entries just as easily as MokList entries, or any other
variables.

The fact that keys can be injected is true with or without this patch,
though it does make it easier.  But making a boot loader that injects
keys into the kernel's built-in keyring isn't actually very difficult.

If you're not using firmware enforced SB and shim, you do not have
security against this.

-- 
        Peter

[toc] | [prev] | [next] | [standalone]

#1527004

On 21 November 2016 at 20:18, Peter Jones <pjones@redhat.com> wrote:
> On Mon, Nov 21, 2016 at 08:06:44PM +0100, Ard Biesheuvel wrote:
>> On 21 November 2016 at 20:05, Peter Jones <pjones@redhat.com> wrote:
>> > On Mon, Nov 21, 2016 at 04:42:45PM +0000, Ard Biesheuvel wrote:
>> >> On 21 November 2016 at 16:26, Josh Boyer <jwboyer@fedoraproject.org> wrote:
>> >> > On Mon, Nov 21, 2016 at 11:18 AM, Ard Biesheuvel
>> >> > <ard.biesheuvel@linaro.org> wrote:
>> >> >> On 16 November 2016 at 18:11, David Howells <dhowells@redhat.com> wrote:
>> >> >>> From: Josh Boyer <jwboyer@fedoraproject.org>
>> >> >>>
>> >> >>> If a user tells shim to not use the certs/hashes in the UEFI db variable
>> >> >>> for verification purposes, shim will set a UEFI variable called
>> >> >>> MokIgnoreDB.  Have the uefi import code look for this and ignore the db
>> >> >>> variable if it is found.
>> >> >>>
>> >> >>
>> >> >> Similar concern as in the previous patch: it appears to me that you
>> >> >> can DoS a machine by setting MokIgnoreDB if, e.g., its modules are
>> >> >> signed against a cert that resides in db, and shim/mokmanager are not
>> >> >> being used.
>> >> >
>> >> > If shim/mokmanager aren't used, then you can't actually modify
>> >> > MokIgnoreDB.  Again, it requires physical access and a reboot into
>> >> > mokmanager to actually take effect.
>> >> >
>> >>
>> >> This does the trick as well
>> >>
>> >> printf "\x07\x00\x00\x00\x01" >
>> >> /sys/firmware/efi/efivars/MokIgnoreDB-605dab50-e046-4300-abb6-3dd810dd8b23
>> >
>> > So that really means two things.  First, kernel should only honor any of
>> > the Mok* variables if they're Boot Services-only variables.  Second, to
>> > avoid the DoS, shim should create them all as Boot Services-only the
>> > first time it boots.  That'll prevent them from being created post-boot.
>> >
>>
>> All of that assumes you are using shim and mokmanager in the first place.
>
> No, it doesn't.  If you're not using shim, there's no DoS problem,
> because what would you be DoSing?

Well, if I lose the ability to load modules that have been signed with
a key that resides in db, simply because someone managed to set a
variable that the kernel treats as 'special' even though I am not
using shim/mok in the first place, I would call that an effective DoS
if that means I cannot find my root partition anymore. I suppose
checking for the runtime attribute on the MokIgnoreDB variable
mitigates this somewhat, but it still makes me feel uneasy that the
kernel hardwires variable names that are specific to shim/mokmanager
rather than defined by the UEFI spec.

>  And likewise, if you're not using
> Secure Boot at all, you have no guarantee of anything about your boot
> environment, starting with the idea that the boot loader isn't hostile.
> If you're not using Secure Boot, a hostile pre-boot driver could easily
> add DB entries just as easily as MokList entries, or any other
> variables.
>

I am talking about Secure Boot with shim or MokManager, which are
unlikely to be necessary in many cases on ARM/arm64

> The fact that keys can be injected is true with or without this patch,
> though it does make it easier.  But making a boot loader that injects
> keys into the kernel's built-in keyring isn't actually very difficult.
>
> If you're not using firmware enforced SB and shim, you do not have
> security against this.
>

My objection is against 'magic' variables like MokIgnoreDB and
MokListRT, both of which leave gaping security holes if used in the
proposed way on systems that use Secure Boot but are not using shim or
MokManager.

Adding the contents of MokListRT to the set of trusted keys is a *bad*
idea unless I can be 100% sure that shim/mokmanager were involved in
my boot chain.

[toc] | [prev] | [next] | [standalone]

#1526986 — Re: [PATCH 9/9] MODSIGN: Allow the "db" UEFI variable to be suppressed

On Mon, Nov 21, 2016 at 04:42:45PM +0000, Ard Biesheuvel wrote:
> On 21 November 2016 at 16:26, Josh Boyer <jwboyer@fedoraproject.org> wrote:
> > On Mon, Nov 21, 2016 at 11:18 AM, Ard Biesheuvel
> > <ard.biesheuvel@linaro.org> wrote:
> >> On 16 November 2016 at 18:11, David Howells <dhowells@redhat.com> wrote:
> >>> From: Josh Boyer <jwboyer@fedoraproject.org>
> >>>
> >>> If a user tells shim to not use the certs/hashes in the UEFI db variable
> >>> for verification purposes, shim will set a UEFI variable called
> >>> MokIgnoreDB.  Have the uefi import code look for this and ignore the db
> >>> variable if it is found.
> >>>
> >>
> >> Similar concern as in the previous patch: it appears to me that you
> >> can DoS a machine by setting MokIgnoreDB if, e.g., its modules are
> >> signed against a cert that resides in db, and shim/mokmanager are not
> >> being used.
> >
> > If shim/mokmanager aren't used, then you can't actually modify
> > MokIgnoreDB.  Again, it requires physical access and a reboot into
> > mokmanager to actually take effect.
> >
> 
> This does the trick as well
> 
> printf "\x07\x00\x00\x00\x01" >
> /sys/firmware/efi/efivars/MokIgnoreDB-605dab50-e046-4300-abb6-3dd810dd8b23

So that really means two things.  First, kernel should only honor any of
the Mok* variables if they're Boot Services-only variables.  Second, to
avoid the DoS, shim should create them all as Boot Services-only the
first time it boots.  That'll prevent them from being created post-boot.

-- 
        Peter

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web