linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Casey Schaufler <casey@schaufler-ca.com>
To: "Luis R. Rodriguez" <mcgrof@suse.com>,
	Andy Lutomirski <luto@amacapital.net>,
	Kees Cook <keescook@chromium.org>,
	LSM List <linux-security-module@vger.kernel.org>
Cc: Mimi Zohar <zohar@linux.vnet.ibm.com>,
	Matthew Garrett <mjg59@srcf.ucam.org>,
	Julian Calaby <julian.calaby@gmail.com>,
	Andy Lutomirski <luto@kernel.org>,
	James Morris <james.l.morris@oracle.com>,
	"Serge E. Hallyn" <serge@hallyn.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	linux-wireless <linux-wireless@vger.kernel.org>,
	David Howells <dhowells@redhat.com>,
	Kyle McMartin <kyle@kernel.org>,
	David Woodhouse <david.woodhouse@intel.com>,
	Seth Forshee <seth.forshee@canonical.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Konstantin Ryabitsev <mricon@kernel.org>,
	Michal Marek <mmarek@suse.cz>,
	Abelardo Ricart III <aricart@memnix.com>,
	Sedat Dilek <sedat.dilek@gmail.com>,
	keyrings@linux-nfs.org, Borislav Petkov <bp@alien8.de>,
	Jiri Kosina <jkosina@suse.cz>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Casey Schaufler <casey@schaufler-ca.com>
Subject: Re: [RFD] linux-firmware key arrangement for firmware signing
Date: Thu, 21 May 2015 16:15:24 -0700	[thread overview]
Message-ID: <555E670C.6080901@schaufler-ca.com> (raw)
In-Reply-To: <20150521222626.GI23057@wotan.suse.de>

On 5/21/2015 3:26 PM, Luis R. Rodriguez wrote:
> On Tue, May 19, 2015 at 05:41:37PM -0700, Andy Lutomirski wrote:
>> On Tue, May 19, 2015 at 5:39 PM, Luis R. Rodriguez <mcgrof@suse.com> wrote:
>>> On Tue, May 19, 2015 at 04:42:05PM -0700, Andy Lutomirski wrote:
>>>> On Tue, May 19, 2015 at 4:30 PM, Julian Calaby <julian.calaby@gmail.com> wrote:
>>>>> Hi All,
>>>>>
>>>>> On Wed, May 20, 2015 at 6:59 AM, Andy Lutomirski <luto@kernel.org> wrote:
>>>>>> [added cc's from the other thread]
>>>>>>
>>>>>> On 05/19/2015 01:02 PM, Luis R. Rodriguez wrote:
>>>>>>> David Howells has posted v4 of his series of supporting PKCS#7 for module
>>>>>>> signing. I'm in my v3 series now on RFCs for firmware PKCS#7 support, and
>>>>>>> after
>>>>>>> some review and patch shuffling I think this is ready for patch form.  My
>>>>>>> own
>>>>>>> series however depend on quite a bit of other pending changes, one series
>>>>>>> which
>>>>>>> will go through Rusty's tree, another series of fixes on firmware_class
>>>>>>> which
>>>>>>> should go through Greg's tree. I'll wait until all this and David's own
>>>>>>> patches
>>>>>>> get merged before posting firmware PKCS#7 support. Before all this though
>>>>>>> in
>>>>>>> preparation for fw signing one thing we should start to talk about more
>>>>>>> broadly
>>>>>>> however is how linux-firmware binary file signing would work in practice
>>>>>>> and
>>>>>>> what we need, and make sure folks are OK with all this.
>>>>>>>
>>>>>>> First, firmware signing will be completely optional as with module
>>>>>>> signing.
>>>>>>>
>>>>>> ...
>>>>>>
>>>>>>> Other than this last nitpick, any other concerns or recommendations ?
>>>>>>
>>>>>> A couple.  Some of these are general concerns with the existing
>>>>>> infrastructure, but #1 is a specific problem that gets much worse if we add
>>>>>> firmware signing.  Feel free to ignore 2-4.
>>>>>>
>>>>>> 1. We should get the signature semantics right.  I think that, for modules,
>>>>>> we currently sign literally the module payload.  For modules, in my
>>>>>> semi-amateurish crypto universe [1], this is fine *as long as the key in
>>>>>> question is used for no other purpose*.  For firmware, it's dangerous, since
>>>>>> it would be vulnerable to substitution attacks in which the adversary
>>>>>> convinces us to interpret one firmware file as firmware for another device
>>>>>> or purpose entirely.
>>>>>>
>>>>>> We should be signing something that's semantically equivalent to "This is a
>>>>>> valid module: xyz", "This is a valid 'regulatory.bin': xyz", or "This is a
>>>>>> valid kexec image: xyz".
>>>>> Something that occurred to me (as a complete bystander) was: would it
>>>>> make sense to have keys able to be restricted to particular "types" of
>>>>> signable data? I.e. the key that can sign a valid regulatory.bin file
>>>>> cannot be used to sign a module or a kexec image. - This could remove
>>>>> the need to have multiple keyrings. (Also, UEFI keys unless otherwise
>>>>> tagged could be restricted to only signing bootloaders or kernels)
>>>> Seems sensible to me.
>>> As for having keys for fw signing be specific to fw data without a keyring,
>>> if that is desirable I think we can devise a way to do that. For instance
>>> if we wanted to we can have FW_SIG by default trust first keys on
>>> system_trusted_keyring just as module signature works -- or if we wanted to
>>> just trust, say a Kyle key. Not sure if the later is possible yet, but htat
>>> would require some changes. Then as an evolution if we wanted to enable a
>>> specific request fw to be mapped to a specific fw file the new APIs I was
>>> looking to add could easily enable this provided that we first decide we
>>> do want to trust say one key perhaps not on system_trusted_keyring for fw
>>> signing. That'd need to be decided first.
>>>
>>> As for the UEFI stuff -- from what I gather its too late there. We could
>>> certainly go with something else for fw signing though, just lemme hear it
>>> hard and clear.
>>>
>>>> FWIW, I'm starting to think that UEFI-based validation of kexec images
>>>> should be totally separate.  It uses a nasty PE format with a hideous
>>>> PKCS #7 formatted signature.  Maybe that should be a completely
>>>> separate piece of code.
>>> LSM'ify it I guess? Again, if that's reasonable then I think we'll need
>>> stacking and that's still not merged.
>> Isn't stacking backwards for this, though?  The semantics we'd want is
>> accept if any verifiers accept, not accept if all verifiers accept,
>> right?
> That can be added, and if stacking is not yet merged perhaps Casey can
> consider it?

So long as the net result coming out of an module is a yes/no answer,
and so long as you're not using any of the security blobs there's no
reason you can't stack exactly like Yama. Within your module you can
enforce an aggressive grant policy if you like, returning -EACCES only
if all your verifiers fail.


>
>   Luis
>


  reply	other threads:[~2015-05-21 23:22 UTC|newest]

Thread overview: 61+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-19 20:02 [RFD] linux-firmware key arrangement for firmware signing Luis R. Rodriguez
2015-05-19 20:40 ` Luis R. Rodriguez
2015-05-19 20:59 ` Andy Lutomirski
2015-05-19 22:11   ` Luis R. Rodriguez
2015-05-19 22:40     ` Andy Lutomirski
2015-05-19 23:30   ` Julian Calaby
2015-05-19 23:42     ` Andy Lutomirski
2015-05-20  0:39       ` Luis R. Rodriguez
2015-05-20  0:41         ` Andy Lutomirski
2015-05-21 22:26           ` Luis R. Rodriguez
2015-05-21 23:15             ` Casey Schaufler [this message]
2015-05-21 15:51   ` David Howells
2015-05-21 16:30     ` Mimi Zohar
2015-05-21 16:39     ` Andy Lutomirski
2015-05-21 16:51       ` Petko Manolov
2015-05-21 16:55         ` Andy Lutomirski
2015-05-21 17:44           ` Petko Manolov
2015-05-21 16:43     ` Petko Manolov
2015-05-21 16:48       ` Andy Lutomirski
2015-05-21 16:58         ` Petko Manolov
2015-05-21 16:59       ` Mimi Zohar
2015-05-19 21:48 ` Mimi Zohar
2015-05-19 22:19   ` Luis R. Rodriguez
2015-05-19 23:37     ` Mimi Zohar
2015-05-20  0:22       ` Luis R. Rodriguez
2015-05-20  1:06         ` Mimi Zohar
2015-05-20  1:29           ` Andy Lutomirski
2015-05-20  2:05             ` Mimi Zohar
2015-05-20  2:10               ` Andy Lutomirski
2015-05-20 15:49                 ` Petko Manolov
2015-05-20 16:08         ` Petko Manolov
2015-05-20 14:04 ` Seth Forshee
2015-05-20 16:24   ` One Thousand Gnomes
2015-05-20 16:46     ` Petko Manolov
2015-05-21  4:41       ` Greg Kroah-Hartman
2015-05-21  5:41         ` Petko Manolov
2015-05-21  6:14           ` Greg Kroah-Hartman
2015-05-21 13:05             ` Mimi Zohar
2015-05-21 15:45               ` Greg Kroah-Hartman
2015-05-21 15:53                 ` Petko Manolov
2015-05-21 16:57                   ` Greg Kroah-Hartman
2015-05-26 17:08                   ` One Thousand Gnomes
2015-05-26 19:15                     ` Petko Manolov
2015-05-26 19:52                     ` Mimi Zohar
2015-05-26 23:06                   ` David Howells
2015-05-21 16:03                 ` Woodhouse, David
2015-05-21 16:22                   ` Mimi Zohar
2015-05-21 16:31                     ` Woodhouse, David
2015-05-21 17:02                   ` gregkh
2015-05-21 17:14                     ` Petko Manolov
2015-05-21 18:23                     ` Luis R. Rodriguez
2015-05-21 18:30                       ` Luis R. Rodriguez
2015-05-21 19:32                     ` Woodhouse, David
2015-05-21 17:49                   ` Luis R. Rodriguez
2015-05-21 14:45             ` Petko Manolov
2015-05-21 22:50     ` Luis R. Rodriguez
2015-05-20 20:35   ` Kyle McMartin
2015-05-20 15:08 ` David Howells
2015-05-20 15:47   ` Seth Forshee
2015-05-21 16:23   ` David Howells
2015-05-20 15:14 ` David Howells

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=555E670C.6080901@schaufler-ca.com \
    --to=casey@schaufler-ca.com \
    --cc=aricart@memnix.com \
    --cc=bp@alien8.de \
    --cc=david.woodhouse@intel.com \
    --cc=dhowells@redhat.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=james.l.morris@oracle.com \
    --cc=jkosina@suse.cz \
    --cc=julian.calaby@gmail.com \
    --cc=keescook@chromium.org \
    --cc=keyrings@linux-nfs.org \
    --cc=kyle@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=luto@kernel.org \
    --cc=mcgrof@suse.com \
    --cc=mjg59@srcf.ucam.org \
    --cc=mmarek@suse.cz \
    --cc=mricon@kernel.org \
    --cc=sedat.dilek@gmail.com \
    --cc=serge@hallyn.com \
    --cc=seth.forshee@canonical.com \
    --cc=torvalds@linux-foundation.org \
    --cc=zohar@linux.vnet.ibm.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: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).