From: Mimi Zohar <zohar@linux.vnet.ibm.com> To: David Howells <dhowells@redhat.com> Cc: Petko Manolov <petkan@mip-labs.com>, keyrings@vger.kernel.org, matthew.garrett@nebula.com, linux-security-module@vger.kernel.org, linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org, linux-ima-devel <linux-ima-devel@lists.sourceforge.net> Subject: Re: [PATCH 4/9] KEYS: Allow unrestricted boot-time addition of keys to secondary keyring Date: Mon, 21 Nov 2016 09:04:55 -0500 [thread overview] Message-ID: <1479737095.2487.34.camel@linux.vnet.ibm.com> (raw) In-Reply-To: <26349.1479376560@warthog.procyon.org.uk> On Thu, 2016-11-17 at 09:56 +0000, David Howells wrote: > Petko Manolov <petkan@mip-labs.com> wrote: > > > On 16-11-16 18:11:13, David Howells wrote: > > > Allow keys to be added to the system secondary certificates keyring during > > > kernel initialisation in an unrestricted fashion. Such keys are implicitly > > > trusted and don't have their trust chains checked on link. > > > > Well, I for one do not explicitly trust these keys. I may even want to > > completely remove or replace them. > > Fine be me. However, if you remove them all I would guess that you cannot > perform a secure boot. > > Note that it's to be expected that the keys being loaded from the UEFI > database cannot have their signatures checked - which is why they would have > to be implicitly trusted. For the same reason, the kernel does not check the > signatures on the keys compiled into the kernel image. Sigh, we've been here before, discussed this before. Different keys should be trusted at different levels. Nothing has changed. Just because I trust a key in UEFI for UEFI, doesn't mean that I trust that same key once the kernel has booted. This time not only are you bringing the keys from UEFI up to the kernel, but by adding these keys to the secondary trusted keyring, they are allowed to add other keys they've signed to the secondary trusted keyring. If the UEFI keys are just for verifying kernel modules, why not define a separate UEFI keyring, which can be used, if enabled, just for verifying kernel modules, instead of affecting all signature verification? IMA's root of trust goes back to UEFI, but transitions to the builtin kernel keyring and, if enabled, the secondary keyring on boot. > > > This allows keys in the UEFI database to be added in secure boot mode for > > > the purposes of module signing. > > > > The key import should not be automatic, it should be optional. > > You can argue this either way. There's a config option to allow you to turn > this on or off. Arguably, this should be split in two: one for the whitelist > (db, MokListRT) and one for the blacklist (dbx). By "config", you're not referring to a Kconfig option, but a UEFI db option, making it hidden/unknown to someone building a kernel. If you really want to add this support, make it clear and easily seen by defining a "restrict_link_by_builtin_or_uefi" function. Mimi
WARNING: multiple messages have this Message-ID (diff)
From: Mimi Zohar <zohar-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org> To: David Howells <dhowells-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> Cc: Petko Manolov <petkan-5DSaK1yNf91Wk0Htik3J/w@public.gmane.org>, keyrings-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, matthew.garrett-05XSO3Yj/JvQT0dZR+AlfA@public.gmane.org, linux-security-module-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-ima-devel <linux-ima-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org> Subject: Re: [PATCH 4/9] KEYS: Allow unrestricted boot-time addition of keys to secondary keyring Date: Mon, 21 Nov 2016 09:04:55 -0500 [thread overview] Message-ID: <1479737095.2487.34.camel@linux.vnet.ibm.com> (raw) In-Reply-To: <26349.1479376560-S6HVgzuS8uM4Awkfq6JHfwNdhmdF6hFW@public.gmane.org> On Thu, 2016-11-17 at 09:56 +0000, David Howells wrote: > Petko Manolov <petkan-5DSaK1yNf91Wk0Htik3J/w@public.gmane.org> wrote: > > > On 16-11-16 18:11:13, David Howells wrote: > > > Allow keys to be added to the system secondary certificates keyring during > > > kernel initialisation in an unrestricted fashion. Such keys are implicitly > > > trusted and don't have their trust chains checked on link. > > > > Well, I for one do not explicitly trust these keys. I may even want to > > completely remove or replace them. > > Fine be me. However, if you remove them all I would guess that you cannot > perform a secure boot. > > Note that it's to be expected that the keys being loaded from the UEFI > database cannot have their signatures checked - which is why they would have > to be implicitly trusted. For the same reason, the kernel does not check the > signatures on the keys compiled into the kernel image. Sigh, we've been here before, discussed this before. Different keys should be trusted at different levels. Nothing has changed. Just because I trust a key in UEFI for UEFI, doesn't mean that I trust that same key once the kernel has booted. This time not only are you bringing the keys from UEFI up to the kernel, but by adding these keys to the secondary trusted keyring, they are allowed to add other keys they've signed to the secondary trusted keyring. If the UEFI keys are just for verifying kernel modules, why not define a separate UEFI keyring, which can be used, if enabled, just for verifying kernel modules, instead of affecting all signature verification? IMA's root of trust goes back to UEFI, but transitions to the builtin kernel keyring and, if enabled, the secondary keyring on boot. > > > This allows keys in the UEFI database to be added in secure boot mode for > > > the purposes of module signing. > > > > The key import should not be automatic, it should be optional. > > You can argue this either way. There's a config option to allow you to turn > this on or off. Arguably, this should be split in two: one for the whitelist > (db, MokListRT) and one for the blacklist (dbx). By "config", you're not referring to a Kconfig option, but a UEFI db option, making it hidden/unknown to someone building a kernel. If you really want to add this support, make it clear and easily seen by defining a "restrict_link_by_builtin_or_uefi" function. Mimi
next prev parent reply other threads:[~2016-11-21 14:05 UTC|newest] Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-11-16 18:10 [PATCH 0/9] KEYS: Blacklisting & UEFI database load David Howells 2016-11-16 18:10 ` David Howells 2016-11-16 18:10 ` [PATCH 1/9] KEYS: Add a system blacklist keyring David Howells 2016-11-16 18:10 ` [PATCH 2/9] X.509: Allow X.509 certs to be blacklisted David Howells 2016-11-16 18:11 ` [PATCH 3/9] PKCS#7: Handle blacklisted certificates David Howells 2016-11-16 18:11 ` [PATCH 4/9] KEYS: Allow unrestricted boot-time addition of keys to secondary keyring David Howells 2016-11-17 6:41 ` Petko Manolov 2016-11-17 9:56 ` David Howells 2016-11-17 10:22 ` Petko Manolov 2016-11-17 10:22 ` Petko Manolov 2016-11-17 11:18 ` David Howells 2016-11-17 11:18 ` David Howells 2016-11-21 14:04 ` Mimi Zohar [this message] 2016-11-21 14:04 ` Mimi Zohar 2016-11-21 15:17 ` David Howells 2016-11-21 16:24 ` Mimi Zohar 2016-11-16 18:11 ` [PATCH 5/9] efi: Add SHIM and image security database GUID definitions David Howells 2016-11-21 16:07 ` Ard Biesheuvel 2016-11-16 18:11 ` [PATCH 6/9] efi: Add EFI signature data types David Howells 2016-11-16 23:43 ` Mat Martineau 2016-11-17 9:44 ` David Howells 2016-11-17 9:44 ` David Howells 2016-11-21 16:08 ` Ard Biesheuvel 2016-11-21 16:08 ` Ard Biesheuvel 2016-11-16 18:11 ` [PATCH 7/9] efi: Add an EFI signature blob parser David Howells 2016-11-16 18:11 ` [PATCH 8/9] MODSIGN: Import certificates from UEFI Secure Boot David Howells 2016-11-21 16:16 ` Ard Biesheuvel 2016-11-21 16:25 ` Josh Boyer 2016-11-21 16:25 ` Josh Boyer 2016-11-24 19:22 ` James Bottomley 2016-11-24 19:22 ` James Bottomley 2016-11-24 19:17 ` James Bottomley 2016-11-24 19:17 ` James Bottomley 2016-12-02 18:57 ` James Bottomley 2016-12-02 20:18 ` Mimi Zohar 2016-11-16 18:11 ` [PATCH 9/9] MODSIGN: Allow the "db" UEFI variable to be suppressed David Howells 2016-11-21 16:18 ` Ard Biesheuvel 2016-11-21 16:18 ` Ard Biesheuvel 2016-11-21 16:26 ` Josh Boyer 2016-11-21 16:26 ` Josh Boyer 2016-11-21 16:42 ` Ard Biesheuvel 2016-11-21 16:42 ` Ard Biesheuvel 2016-11-21 19:05 ` Peter Jones 2016-11-21 19:05 ` Peter Jones 2016-11-21 19:06 ` Ard Biesheuvel 2016-11-21 19:18 ` Peter Jones 2016-11-21 19:33 ` Ard Biesheuvel 2018-03-06 14:05 ` [PATCH 0/9] KEYS: Blacklisting & UEFI database load Jiri Slaby 2018-03-06 14:05 ` Jiri Slaby 2018-03-06 14:05 ` Jiri Slaby 2018-03-07 13:18 ` Mimi Zohar 2018-03-07 13:18 ` Mimi Zohar 2018-03-07 13:18 ` Mimi Zohar 2018-03-07 15:28 ` James Bottomley 2018-03-07 15:28 ` James Bottomley 2018-03-07 15:28 ` James Bottomley 2018-03-11 3:20 ` joeyli 2018-03-11 3:20 ` joeyli 2018-03-11 3:20 ` joeyli 2018-03-19 14:12 ` Mimi Zohar 2018-03-19 14:12 ` Mimi Zohar 2018-03-19 14:12 ` Mimi Zohar 2018-03-27 11:08 ` joeyli 2018-03-27 11:08 ` joeyli 2018-03-27 11:08 ` joeyli
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=1479737095.2487.34.camel@linux.vnet.ibm.com \ --to=zohar@linux.vnet.ibm.com \ --cc=dhowells@redhat.com \ --cc=keyrings@vger.kernel.org \ --cc=linux-efi@vger.kernel.org \ --cc=linux-ima-devel@lists.sourceforge.net \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-security-module@vger.kernel.org \ --cc=matthew.garrett@nebula.com \ --cc=petkan@mip-labs.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.