[Ksummit-discuss] Last minute nominations: mcgrof and toshi

[Ksummit-discuss] Last minute nominations: mcgrof and toshi

[Luis R. Rodriguez]

Ted noted to send last minute self nominations by Wednesday.  This is my last
minute self nomination, I'm also making a last minute nominating for Toshi.

I would like to nominate myself for this years KS.  I've already been
summoned about these topics through this list and confirm interest
in participating in these discussions:

 * Semantics of MMIO mapping attributes accross archs
 * Signature management - keys, modules, firmware.

I haven't seen Toshi on the list of nominated folks but I do think that having
Toshi present would be crucial for the semantics over MMIO mapping discussion,
if he could make it, so Cc'ing him and also making a last minute nomination for
him.

But I'm also interested in these other topics as well:

 * Recruitment
 * Compute-Offload Devices
 * Testing
 * Documentation
 * GPL Enforcement

In general I'm very interested in the long term over how we can scale the pace
of Linux kernel development and not only manage it but see how we can actually
do it better and faster if needed. So I'm very interested in topics  such as
semantics and tools to help with maintainer's work, deprecating drivers, bug
finding, recruitment, education, testing, and automatically backporting the
kernel. In particular in the last few years I've been paying close attention
towards what we could do better when introducing in new APIs, as that would be
a good place to test new ideas and quickly make bad ones fail.

  Luis

Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi

[Toshi Kani]

On Tue, 2015-08-04 at 17:26 +0200, Luis R. Rodriguez wrote:
> Ted noted to send last minute self nominations by Wednesday.  This is my 
> last minute self nomination, I'm also making a last minute nominating for
> Toshi.
> 
> I would like to nominate myself for this years KS.  I've already been
> summoned about these topics through this list and confirm interest
> in participating in these discussions:
> 
>  * Semantics of MMIO mapping attributes accross archs
>  * Signature management - keys, modules, firmware.
> 
> I haven't seen Toshi on the list of nominated folks but I do think that 
> having Toshi present would be crucial for the semantics over MMIO mapping
> discussion, if he could make it, so Cc'ing him and also making a last 
> minute nomination for him.

Thanks Luis!  Yes, I'd like to participate the MMIO mapping discussion. 

-Toshi

Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi

[Mimi Zohar]

On Di, 2015-08-04 at 17:26 +0200, Luis R. Rodriguez wrote:
> Ted noted to send last minute self nominations by Wednesday.  This is my last
> minute self nomination, I'm also making a last minute nominating for Toshi.
> 
> I would like to nominate myself for this years KS.  I've already been
> summoned about these topics through this list and confirm interest
> in participating in these discussions:
> 
>  * Semantics of MMIO mapping attributes accross archs
>  * Signature management - keys, modules, firmware.

I'd also like to participate in this discussion.

Mimi

Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi

[Mimi Zohar]

Oops, "Signature management - keys, modules, firmware" was a suggestion
from last year, but in my opinion still very apropos.

Mimi

Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 343 bytes --]

On Fri, Jul 15, 2016 at 03:57:51PM -0400, Mimi Zohar wrote:

> Oops, "Signature management - keys, modules, firmware" was a suggestion
> from last year, but in my opinion still very apropos.

Yup, definitely - especially with secure boot starting to firm up on the
ARM side there's a bunch more interest in it from more embedded
applications.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi

[David Woodhouse]

[-- Attachment #1: Type: text/plain, Size: 745 bytes --]

On Sat, 2016-07-16 at 01:52 +0100, Mark Brown wrote:
> On Fri, Jul 15, 2016 at 03:57:51PM -0400, Mimi Zohar wrote:
> 
> > Oops, "Signature management - keys, modules, firmware" was a suggestion
> > from last year, but in my opinion still very apropos.
> 
> Yup, definitely - especially with secure boot starting to firm up on the
> ARM side there's a bunch more interest in it from more embedded
> applications.

Are we going to propose this again "formally" (i.e. sufficiently
clearly that the committee take note and consider it)?

If so, I would also be keen to participate.

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse@intel.com                              Intel Corporation

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5760 bytes --]

[Ksummit-discuss] [TECH TOPIC] Signature management - keys, modules, firmware, was: Last minute nominations: mcgrof and toshi

[Jason Cooper]

Hi David,

On Tue, Jul 26, 2016 at 03:42:18PM +0100, David Woodhouse wrote:
> On Sat, 2016-07-16 at 01:52 +0100, Mark Brown wrote:
> > On Fri, Jul 15, 2016 at 03:57:51PM -0400, Mimi Zohar wrote:
> > 
> > > Oops, "Signature management - keys, modules, firmware" was a
> > > suggestion from last year, but in my opinion still very apropos.
> > 
> > Yup, definitely - especially with secure boot starting to firm up on
> > the ARM side there's a bunch more interest in it from more embedded
> > applications.
> 
> Are we going to propose this again "formally" (i.e. sufficiently
> clearly that the committee take note and consider it)?

$subject modified.

> If so, I would also be keen to participate.

Myself as well.  I've often wondered about devicetree signing.  Since it
needs to be modified by the bootloader in a lot of cases (RAM size,
cmdline, etc), but a malicious modification would be to remove the TPM
node. :-)

thx,

Jason.

Re: [Ksummit-discuss] [TECH TOPIC] Signature management - keys, modules, firmware, was: Last minute nominations: mcgrof and toshi

[Mark Rutland]

On Wed, Jul 27, 2016 at 02:04:06PM +0000, Jason Cooper wrote:
> Hi David,
> 
> On Tue, Jul 26, 2016 at 03:42:18PM +0100, David Woodhouse wrote:
> > On Sat, 2016-07-16 at 01:52 +0100, Mark Brown wrote:
> > > On Fri, Jul 15, 2016 at 03:57:51PM -0400, Mimi Zohar wrote:
> > > 
> > > > Oops, "Signature management - keys, modules, firmware" was a
> > > > suggestion from last year, but in my opinion still very apropos.
> > > 
> > > Yup, definitely - especially with secure boot starting to firm up on
> > > the ARM side there's a bunch more interest in it from more embedded
> > > applications.
> > 
> > Are we going to propose this again "formally" (i.e. sufficiently
> > clearly that the committee take note and consider it)?
> 
> $subject modified.
> 
> > If so, I would also be keen to participate.
> 
> Myself as well.  I've often wondered about devicetree signing.  Since it
> needs to be modified by the bootloader in a lot of cases (RAM size,
> cmdline, etc), but a malicious modification would be to remove the TPM
> node. :-)

I'd be interested in these discussions.

Mark.

Re: [Ksummit-discuss] [TECH TOPIC] Signature management - keys, modules, firmware, was: Last minute nominations: mcgrof and toshi

[Stephen Hemminger]

On Wed, 27 Jul 2016 14:04:06 +0000
Jason Cooper <jason@lakedaemon.net> wrote:

> Hi David,
> 
> On Tue, Jul 26, 2016 at 03:42:18PM +0100, David Woodhouse wrote:
> > On Sat, 2016-07-16 at 01:52 +0100, Mark Brown wrote:  
> > > On Fri, Jul 15, 2016 at 03:57:51PM -0400, Mimi Zohar wrote:
> > >   
> > > > Oops, "Signature management - keys, modules, firmware" was a
> > > > suggestion from last year, but in my opinion still very apropos.  
> > > 
> > > Yup, definitely - especially with secure boot starting to firm up on
> > > the ARM side there's a bunch more interest in it from more embedded
> > > applications.  
> > 
> > Are we going to propose this again "formally" (i.e. sufficiently
> > clearly that the committee take note and consider it)?  
> 
> $subject modified.
> 
> > If so, I would also be keen to participate.  
> 
> Myself as well.  I've often wondered about devicetree signing.  Since it
> needs to be modified by the bootloader in a lot of cases (RAM size,
> cmdline, etc), but a malicious modification would be to remove the TPM
> node. :-)

I am interested in this as well because of issues in creating secure guests.

Re: [Ksummit-discuss] [TECH TOPIC] Signature management - keys, modules, firmware, was: Last minute nominations: mcgrof and toshi

[Andy Lutomirski]

[-- Attachment #1: Type: text/plain, Size: 1293 bytes --]

On Jul 27, 2016 11:16 AM, "Stephen Hemminger" <stephen@networkplumber.org>
wrote:
>
> On Wed, 27 Jul 2016 14:04:06 +0000
> Jason Cooper <jason@lakedaemon.net> wrote:
>
> > Hi David,
> >
> > On Tue, Jul 26, 2016 at 03:42:18PM +0100, David Woodhouse wrote:
> > > On Sat, 2016-07-16 at 01:52 +0100, Mark Brown wrote:
> > > > On Fri, Jul 15, 2016 at 03:57:51PM -0400, Mimi Zohar wrote:
> > > >
> > > > > Oops, "Signature management - keys, modules, firmware" was a
> > > > > suggestion from last year, but in my opinion still very apropos.
> > > >
> > > > Yup, definitely - especially with secure boot starting to firm up on
> > > > the ARM side there's a bunch more interest in it from more embedded
> > > > applications.
> > >
> > > Are we going to propose this again "formally" (i.e. sufficiently
> > > clearly that the committee take note and consider it)?
> >
> > $subject modified.
> >
> > > If so, I would also be keen to participate.
> >
> > Myself as well.  I've often wondered about devicetree signing.  Since it
> > needs to be modified by the bootloader in a lot of cases (RAM size,
> > cmdline, etc), but a malicious modification would be to remove the TPM
> > node. :-)
>
> I am interested in this as well because of issues in creating secure
guests.
>

I'm interested in this, too.

[-- Attachment #2: Type: text/html, Size: 1883 bytes --]

Re: [Ksummit-discuss] [TECH TOPIC] Signature management - keys, modules, firmware, was: Last minute nominations: mcgrof and toshi

[Ben Hutchings]

[-- Attachment #1: Type: text/plain, Size: 317 bytes --]

I would want to participate in this.  Debian is finally implementing
code signing.

Ben.

-- 

Ben Hutchings
Experience is directly proportional to the value of equipment destroyed.
                                                         - Carolyn Scheppner

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [Ksummit-discuss] [TECH TOPIC] Signature management - keys, modules, firmware, was: Last minute nominations: mcgrof and toshi

[Mimi Zohar]

On Fri, 2016-07-29 at 13:29 +0100, Ben Hutchings wrote:
> I would want to participate in this.  Debian is finally implementing
> code signing.

Will it be at the package and file levels, or just package level?

Mimi

Re: [Ksummit-discuss] [TECH TOPIC] Signature management - keys, modules, firmware, was: Last minute nominations: mcgrof and toshi

[Ben Hutchings]

[-- Attachment #1: Type: text/plain, Size: 454 bytes --]

On Fri, 2016-08-05 at 13:16 -0400, Mimi Zohar wrote:
> On Fri, 2016-07-29 at 13:29 +0100, Ben Hutchings wrote:
> > 
> > I would want to participate in this.  Debian is finally implementing
> > code signing.
> 
> Will it be at the package and file levels, or just package level?

This is for files only - specifically for EFI executables and kernel
modules.

Ben.

-- 
Ben Hutchings
Sturgeon's Law: Ninety percent of everything is crap.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [Ksummit-discuss] [TECH TOPIC] Signature management - keys, modules, firmware, was: Last minute nominations: mcgrof and toshi

[Linus Walleij]

On Wed, Jul 27, 2016 at 4:04 PM, Jason Cooper <jason@lakedaemon.net> wrote:
> On Tue, Jul 26, 2016 at 03:42:18PM +0100, David Woodhouse wrote:
>> On Sat, 2016-07-16 at 01:52 +0100, Mark Brown wrote:
>> > On Fri, Jul 15, 2016 at 03:57:51PM -0400, Mimi Zohar wrote:
>> >
>> > > Oops, "Signature management - keys, modules, firmware" was a
>> > > suggestion from last year, but in my opinion still very apropos.
>> >
>> > Yup, definitely - especially with secure boot starting to firm up on
>> > the ARM side there's a bunch more interest in it from more embedded
>> > applications.
>>
>> Are we going to propose this again "formally" (i.e. sufficiently
>> clearly that the committee take note and consider it)?
>
> $subject modified.
>
>> If so, I would also be keen to participate.
>
> Myself as well.  I've often wondered about devicetree signing.  Since it
> needs to be modified by the bootloader in a lot of cases (RAM size,
> cmdline, etc), but a malicious modification would be to remove the TPM
> node. :-)

Actually the way it works (IIUC) in the only set-up I've seen which is
the Firmware Image Tree (FIT). This blobs a signed kernel+device
tree+initrd (optional) and signs it using e.g. an RSA2048 keypair,
the blob is signature-checked by U-Boot against a compiled-in
public key, then the constituent parts are split, the device tree
augmented and the kernel booted. I.e. U-Boot checks the signature
of the whole shebang *before* augmenting the device tree.

The chain of trust (who watches the watchmen) need to make
sure that U-Boot and its compiled-in certificate are signature-checked
*before* execution of U-Boot, so another boot stage needs to do that.

As far as I've heard, this is what the ARM Chromebooks are doing.

Details:
http://www.denx-cs.de/doku/?q=m28verifiedboot

The overall questions is interesting too.

What I always intuitively felt is that I would be happy if the same
GPG keys we use for pull requests of kernel code would extend
to firmware signing, so that we move from the overall-industry
focus on legislative bodies (Thawte, ...) signing certificates with
OpenSSL and thus being the root of trust, over to putting the root
of trust for any software related to Linux into the same web of
trust that we already use for developing the code per se.

I would certainly trust a firmware signed by say Laurent Pinchart,
but not sure about one signed by E.Corp.

Probably someone will get me for my naïvity on the subject,
but uninformed as I may be, I speak anyway. People still tell me
that "Joe Doe's" doesn't trust kernel devs but they trust
$OPAQUE_CORPORATION for reasons unbeknownst to me.

Yours,
Linus Walleij

Re: [Ksummit-discuss] [TECH TOPIC] Signature management - keys, modules, firmware, was: Last minute nominations: mcgrof and toshi

[Jason Cooper]

Hey Linus,

On Tue, Aug 02, 2016 at 02:54:19PM +0200, Linus Walleij wrote:
> On Wed, Jul 27, 2016 at 4:04 PM, Jason Cooper <jason@lakedaemon.net> wrote:
...
> > Myself as well.  I've often wondered about devicetree signing.  Since it
> > needs to be modified by the bootloader in a lot of cases (RAM size,
> > cmdline, etc), but a malicious modification would be to remove the TPM
> > node. :-)
> 
> Actually the way it works (IIUC) in the only set-up I've seen which is
> the Firmware Image Tree (FIT). This blobs a signed kernel+device
> tree+initrd (optional) and signs it using e.g. an RSA2048 keypair,
> the blob is signature-checked by U-Boot against a compiled-in
> public key, then the constituent parts are split, the device tree
> augmented and the kernel booted. I.e. U-Boot checks the signature
> of the whole shebang *before* augmenting the device tree.
> 
> The chain of trust (who watches the watchmen) need to make
> sure that U-Boot and its compiled-in certificate are signature-checked
> *before* execution of U-Boot, so another boot stage needs to do that.
> 
> As far as I've heard, this is what the ARM Chromebooks are doing.
> 
> Details:
> http://www.denx-cs.de/doku/?q=m28verifiedboot

Ah, thanks for the info. :)

> The overall questions is interesting too.
> 
> What I always intuitively felt is that I would be happy if the same
> GPG keys we use for pull requests of kernel code would extend
> to firmware signing, so that we move from the overall-industry
> focus on legislative bodies (Thawte, ...) signing certificates with
> OpenSSL and thus being the root of trust, over to putting the root
> of trust for any software related to Linux into the same web of
> trust that we already use for developing the code per se.

You're actually hitting at the core of the problem.  The CA system
(Thawte, Verisign, etc) is better than what came before it.  We now have
enough experience with it, and have seen the band-aids [0], to know we need
something better.

The problem here is that we (users) need to be able to verify that
iwlwifi-whatever.ucode claimed to be created by Intel, was indeed the
*same* one Intel shipped out the door.  That's it.  It's up to the user
to decide to "trust" Intel's microcode or not.  All the kernel should be
doing is confirming cryptographically that it came from Intel.

Now, the CA vice Web-of-trust question is "Is this public key the proper
public key for Intel?"  There's several ways to solve this, and they
aren't mutually exclusive:

 - Use the CA to verify you have the correct key
 - Use PGP counter-signing to sign Intel's key (kernel devs could do
   this according to pre-determined authenticity criteria)
 - Use TOFU (Trust on First Use) to confirm that your firmware file is
   signed with the *same* key for each subsequent version
 - Use crowd-sourcing to confirm that everyone else has the same public
   key for Intel

Each approach has it's pluses and minuses, so a combination of
approaches is probably the most viable.

> I would certainly trust a firmware signed by say Laurent Pinchart,
> but not sure about one signed by E.Corp.
> 
> Probably someone will get me for my naïvity on the subject,
> but uninformed as I may be, I speak anyway. People still tell me
> that "Joe Doe's" doesn't trust kernel devs but they trust
> $OPAQUE_CORPORATION for reasons unbeknownst to me.

If I, as a user, buy a laptop with an NVidia GPU, then I just created a
trust relationship with NVidia.  Wether I'm conscious of it or not
doesn't matter.  I put my personal life inside a machine containing the
GPU which has DMA access across the whole system.

So, when I load firmware or drivers for the NVidia GPU, I want to know
that they are indeed from the same entity that created the GPU.  Having
those blobs signed by anyone else, doesn't mean squat to me.

Unless the signer is saying "I, as an outside third party, have reviewed
the source code and binaries for this blob and can confirm that it does
what it is intended to do.  And nothing more." iow, no backdoors were
found, etc.  Then the *extra* signature would have value.  *If* I trust
the signer and have his/her public key, etc.

The point is that only end users can trust.  The kernel can infer trust
so that userspace doesn't have to prompt for every decision.  e.g. we
see an NVidia GPU, so the user bought a laptop with NVidia in it.  ergo,
it's reasonable to assume that drivers signed by NVidia, for the NVidia
GPU are OK to load once verified.

thx,

Jason.

[0] I refer to certificate pinning, a la HPKP; SSL Observatory,
Certificate Transparency, etc.

Re: [Ksummit-discuss] [TECH TOPIC] Signature management - keys, modules, firmware, was: Last minute nominations: mcgrof and toshi

[David Woodhouse]

[-- Attachment #1: Type: text/plain, Size: 2137 bytes --]

On Tue, 2016-08-02 at 14:00 +0000, Jason Cooper wrote:
> 
> You're actually hitting at the core of the problem.  The CA system
> (Thawte, Verisign, etc) is better than what came before it.  We now have
> enough experience with it, and have seen the band-aids [0], to know we need
> something better.
> 
> The problem here is that we (users) need to be able to verify that
> iwlwifi-whatever.ucode claimed to be created by Intel, was indeed the
> *same* one Intel shipped out the door.  That's it.  It's up to the user
> to decide to "trust" Intel's microcode or not.  All the kernel should be
> doing is confirming cryptographically that it came from Intel.
> 
> Now, the CA vice Web-of-trust question is "Is this public key the proper
> public key for Intel?"  There's several ways to solve this, and they
> aren't mutually exclusive:
> 
>  - Use the CA to verify you have the correct key
>  - Use PGP counter-signing to sign Intel's key (kernel devs could do
>    this according to pre-determined authenticity criteria)
>  - Use TOFU (Trust on First Use) to confirm that your firmware file is
>    signed with the *same* key for each subsequent version
>  - Use crowd-sourcing to confirm that everyone else has the same public
>    key for Intel
> 
> Each approach has it's pluses and minuses, so a combination of
> approaches is probably the most viable.

The simple solution which had been proposed was to add a variant of
request_firmware() which specified the key(s) which were acceptable for
signing the firmware in question.

So Intel's signing key would be "trusted" merely by virtue of the fact
that it is explicitly referenced by the iwlwifi driver.

If you are able to get changes to the iwlwifi driver accepted by Linus,
then you can change that. But then, if you can sneak bogus changes into
the drivers then you have other attack models anyway, so I don't think
we need to invent more trust schemes to avoid that.

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse@intel.com                              Intel Corporation

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5760 bytes --]

Re: [Ksummit-discuss] [TECH TOPIC] Signature management - keys, modules, firmware, was: Last minute nominations: mcgrof and toshi

[Andy Lutomirski]

[-- Attachment #1: Type: text/plain, Size: 906 bytes --]

On Aug 2, 2016 7:00 AM, "Jason Cooper" <jason@lakedaemon.net> wrote:

>
> The problem here is that we (users) need to be able to verify that
> iwlwifi-whatever.ucode claimed to be created by Intel, was indeed the
> *same* one Intel shipped out the door.  That's it.  It's up to the user
> to decide to "trust" Intel's microcode or not.  All the kernel should be
> doing is confirming cryptographically that it came from Intel.

Except that this particular use case doesn't require any kernel support at
all.  If the goal is that root doesn't want to load a bad firmware, then
root can check whatever signature it wants in userspace.

The point of in-kernel verification is to enforce policies that are
intended to work even if root is compromised.  This includes CRDA-like
policy and MS's Secure Boot policy.  If, while doing this, we get to check
vendor keys too, that's just an added benefit in my book.

[-- Attachment #2: Type: text/html, Size: 1139 bytes --]

Re: [Ksummit-discuss] [TECH TOPIC] Signature management - keys, modules, firmware, was: Last minute nominations: mcgrof and toshi

[James Bottomley]

On Tue, 2016-08-02 at 14:54 +0200, Linus Walleij wrote:
> As far as I've heard, this is what the ARM Chromebooks are doing.
> 
> Details:
> http://www.denx-cs.de/doku/?q=m28verifiedboot

This is actually very similar to the way secure boot works.  I think
the only real difference is that if the UEFI system is verifying
signatures, we use that same signature verification mechanism in grub
(our u-boot equivalent on x86) partly so we don't have to have yet
another possibly buggy copy of openssl and partly because grub seems
not to like signature verification, so it's easier to call out to a
UEFI protocol than it is to insert full openssl in a modification
patch.

> The overall questions is interesting too.
> 
> What I always intuitively felt is that I would be happy if the same
> GPG keys we use for pull requests of kernel code would extend
> to firmware signing, so that we move from the overall-industry
> focus on legislative bodies (Thawte, ...) signing certificates with
> OpenSSL and thus being the root of trust, over to putting the root
> of trust for any software related to Linux into the same web of
> trust that we already use for developing the code per se.

This is the vision that Monkeysphere is based on

http://web.monkeysphere.info/

However, I might trust Joe Doe enough to sign his key; I probably don't
trust any of the people whose keys I've signed to supply firmware or
other install stuff for my laptop without my intervention, so I
definitely don't trust their keys for this purpose.

> I would certainly trust a firmware signed by say Laurent Pinchart,
> but not sure about one signed by E.Corp.

Really?  Assuming E.Corp is the one actually producing the firmware,
why would you say they're less qualified than Laurent to certify their
own firmware.  Half the SCSI chips I see have proprietary firmware. 
 Even if I were willing to sign it, would you really trust my signature
when I can't even decompile it?

> Probably someone will get me for my naïvity on the subject,
> but uninformed as I may be, I speak anyway. People still tell me
> that "Joe Doe's" doesn't trust kernel devs but they trust
> $OPAQUE_CORPORATION for reasons unbeknownst to me.

It depends ... and this is the problem with "trust" it's too fine
grained to map into any network.  If the firmware is binary, why would
you trust anyone other than the vendor who produced it to sign it. 
 What would such a signature even mean if someone else did?  However,
if the firmware is actually open source, like the 53c700 or aic7xxx
firmwares, which are both in the kernel source tree, perhaps you would
trust me to sign it.

James

Re: [Ksummit-discuss] [TECH TOPIC] Signature management - keys, modules, firmware, was: Last minute nominations: mcgrof and toshi

[Linus Walleij]

On Tue, Aug 2, 2016 at 4:13 PM, James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
> On Tue, 2016-08-02 at 14:54 +0200, Linus Walleij wrote:

>> What I always intuitively felt is that I would be happy if the same
>> GPG keys we use for pull requests of kernel code would extend
>> to firmware signing, so that we move from the overall-industry
>> focus on legislative bodies (Thawte, ...) signing certificates with
>> OpenSSL and thus being the root of trust, over to putting the root
>> of trust for any software related to Linux into the same web of
>> trust that we already use for developing the code per se.
>
> This is the vision that Monkeysphere is based on
>
> http://web.monkeysphere.info/

That looks nice.

>> I would certainly trust a firmware signed by say Laurent Pinchart,
>> but not sure about one signed by E.Corp.
>
> Really?  Assuming E.Corp is the one actually producing the firmware,
> why would you say they're less qualified than Laurent to certify their
> own firmware.  Half the SCSI chips I see have proprietary firmware.
>  Even if I were willing to sign it, would you really trust my signature
> when I can't even decompile it?

I would trust an Intel WiFi driver if it was signed by Dirk Hohndel
or H. Peter Anvin whose GPG keys I have in my own web of trust
and work for Intel. And this is simply because I trust these guys
more than the corporate entity they work for.

And when you think of it, that is exactly what the kernel devs
web of trust is doing: we trust these individuals, not the companies
they work for. That is why we are using GPG keys and not
OpenSSL certificates signed by say Linux Foundation to send
our pull requests.

Well maybe I attribute intent where there is none: maybe the
GPG signature in git was just arbitrarily chosen for this, due to
it's availability and/or simplicity it could have been the other way
in a parallel universe that contributors would have to use
certificates signed by LF... I don't know. I'm uncertain.

But I percieve it as if there is some tension here between "our"
individual trust and the corporate trust in legal bodies. I might
be mistaken.

> ... and this is the problem with "trust" it's too fine
> grained to map into any network.  If the firmware is binary, why would
> you trust anyone other than the vendor who produced it to sign it.
>  What would such a signature even mean if someone else did?  However,
> if the firmware is actually open source, like the 53c700 or aic7xxx
> firmwares, which are both in the kernel source tree, perhaps you would
> trust me to sign it.

Being able to inspect the source is paramount and 53x700 and aic7xx
show what is needed if we want a future where we as (power) users can
trust our own devices. If I would recompile any of those two firmwares
myself I guess I would also sign them myself and trust myself.
The inroad to complete trust would be to first read the firmware source
code.

Yours,
Linus Walleij

Re: [Ksummit-discuss] [TECH TOPIC] Signature management - keys, modules, firmware, was: Last minute nominations: mcgrof and toshi

[Jiri Kosina]

On Wed, 3 Aug 2016, Linus Walleij wrote:

> I would trust an Intel WiFi driver if it was signed by Dirk Hohndel or 
> H. Peter Anvin whose GPG keys I have in my own web of trust and work for 
> Intel. 

Dirk no more :p

> And this is simply because I trust these guys more than the corporate 
> entity they work for.

But I fail to see the reasoning here. You implicitly have to trust the 
corporate entity anyway, because you are using the hardware they supplied 
to you. And that hardware certainly didn't go through hpa or Dirk either.

-- 
Jiri Kosina
SUSE Labs

Re: [Ksummit-discuss] [TECH TOPIC] Signature management - keys, modules, firmware, was: Last minute nominations: mcgrof and toshi

[Jani Nikula]

On Wed, 03 Aug 2016, Linus Walleij <linus.walleij@linaro.org> wrote:
> On Tue, Aug 2, 2016 at 4:13 PM, James Bottomley
> <James.Bottomley@hansenpartnership.com> wrote:
>> On Tue, 2016-08-02 at 14:54 +0200, Linus Walleij wrote:
>>> I would certainly trust a firmware signed by say Laurent Pinchart,
>>> but not sure about one signed by E.Corp.
>>
>> Really?  Assuming E.Corp is the one actually producing the firmware,
>> why would you say they're less qualified than Laurent to certify their
>> own firmware.  Half the SCSI chips I see have proprietary firmware.
>>  Even if I were willing to sign it, would you really trust my signature
>> when I can't even decompile it?
>
> I would trust an Intel WiFi driver if it was signed by Dirk Hohndel
> or H. Peter Anvin whose GPG keys I have in my own web of trust
> and work for Intel. And this is simply because I trust these guys
> more than the corporate entity they work for.

[I admittedly didn't read the whole thread, so take this with a grain of
salt, but this stood out.]

I think you're conflating the trust you have in someone or something
actually being who they claim they are with the trust you have in
them. The GPG keys are used for the former, and it's *relatively* easy
to achieve by key signing events and web of trust. The latter is much
harder, and involves all the things you usually have to do to gain trust
in people.

I would imagine we'd want to ensure the firmware blobs actually come
from whoever writes them. I would imagine this would be the company. I
don't think the signatures per se should imply a guarantee of quality,
just that the firmware originates from where it's supposed to originate.

If you insist the individuals you trust sign the blobs, I think you're
putting them under pressure to scrutinize the contents, while they might
not be in a position to do so, like James says.

Side note, Dirk no longer works for Intel, so while you might trust him
personally, I don't think you should trust him to sign Intel binaries...

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center

Re: [Ksummit-discuss] [TECH TOPIC] Signature management - keys, modules, firmware, was: Last minute nominations: mcgrof and toshi

[Linus Walleij]

On Wed, Aug 3, 2016 at 12:28 PM, Jani Nikula <jani.nikula@intel.com> wrote:
> On Wed, 03 Aug 2016, Linus Walleij <linus.walleij@linaro.org> wrote:

>> I would trust an Intel WiFi driver if it was signed by Dirk Hohndel
>> or H. Peter Anvin whose GPG keys I have in my own web of trust
>> and work for Intel. And this is simply because I trust these guys
>> more than the corporate entity they work for.
>
> I think you're conflating the trust you have in someone or something
> actually being who they claim they are with the trust you have in
> them. The GPG keys are used for the former, and it's *relatively* easy
> to achieve by key signing events and web of trust. The latter is much
> harder, and involves all the things you usually have to do to gain trust
> in people.
>
> I would imagine we'd want to ensure the firmware blobs actually come
> from whoever writes them. I would imagine this would be the company. I
> don't think the signatures per se should imply a guarantee of quality,
> just that the firmware originates from where it's supposed to originate.
>
> If you insist the individuals you trust sign the blobs, I think you're
> putting them under pressure to scrutinize the contents, while they might
> not be in a position to do so, like James says.

Well, that is what we insist that people sending is code does. That is
what Signed-off-by and the signed pull requests mean isn't it?
That we trust the person. GPG is just mechanics to make sure it is
really that person which we trust.

As for trusting corporate entities, I understand that I may be
out-of-the-ordinary anarchist when it comes to that, I can certainly
live with the fact that everyone else in the world has no problem with
that and doesn't understand what I'm talking about or why it would
be a problem. It's just like, my opinion, man.

The point is that the kind of trust technology you choose - certificates
or GPG signatures - sort of decides and codifies what it is you trust,
it creates an ontology for this. (I.e. "the world is populated by people
you can trust" vs "the world is populated by legal entities you can
trust".) Choosing one or the other is fine, but should be done consciously
I think.

Yours,
Linus Walleij

Re: [Ksummit-discuss] [TECH TOPIC] Signature management - keys, modules, firmware, was: Last minute nominations: mcgrof and toshi

[Jani Nikula]

On Wed, 03 Aug 2016, Linus Walleij <linus.walleij@linaro.org> wrote:
> On Wed, Aug 3, 2016 at 12:28 PM, Jani Nikula <jani.nikula@intel.com> wrote:
>> On Wed, 03 Aug 2016, Linus Walleij <linus.walleij@linaro.org> wrote:
>
>>> I would trust an Intel WiFi driver if it was signed by Dirk Hohndel
>>> or H. Peter Anvin whose GPG keys I have in my own web of trust
>>> and work for Intel. And this is simply because I trust these guys
>>> more than the corporate entity they work for.
>>
>> I think you're conflating the trust you have in someone or something
>> actually being who they claim they are with the trust you have in
>> them. The GPG keys are used for the former, and it's *relatively* easy
>> to achieve by key signing events and web of trust. The latter is much
>> harder, and involves all the things you usually have to do to gain trust
>> in people.
>>
>> I would imagine we'd want to ensure the firmware blobs actually come
>> from whoever writes them. I would imagine this would be the company. I
>> don't think the signatures per se should imply a guarantee of quality,
>> just that the firmware originates from where it's supposed to originate.
>>
>> If you insist the individuals you trust sign the blobs, I think you're
>> putting them under pressure to scrutinize the contents, while they might
>> not be in a position to do so, like James says.
>
> Well, that is what we insist that people sending is code does. That is
> what Signed-off-by and the signed pull requests mean isn't it?
> That we trust the person. GPG is just mechanics to make sure it is
> really that person which we trust.

Agreed on open source in general, but I'm just not sure this is a good
approach for closed binary blobs. My educated guess is that the people
doing open source generally are not in positions to evaluate the
firmware binaries beyond testing. You would be over extending the
trust. Like Jiri implied, this is comparable to people signing off on
the hardware.

> As for trusting corporate entities, I understand that I may be
> out-of-the-ordinary anarchist when it comes to that, I can certainly
> live with the fact that everyone else in the world has no problem with
> that and doesn't understand what I'm talking about or why it would
> be a problem. It's just like, my opinion, man.

Oh, I do understand. But I fear having individuals sign the binaries
might buy you little more than a warm fuzzy feeling.

> The point is that the kind of trust technology you choose - certificates
> or GPG signatures - sort of decides and codifies what it is you trust,
> it creates an ontology for this. (I.e. "the world is populated by people
> you can trust" vs "the world is populated by legal entities you can
> trust".) Choosing one or the other is fine, but should be done consciously
> I think.

I do not think the divide is quite as strict as you imply, in particular
you could have legal entities in your GPG web of trust. However this is
where I'll eject myself from the discussion; I don't think I can help
with the choice of one or the other technology.

BR,
Jani.

-- 
Jani Nikula, Intel Open Source Technology Center

Re: [Ksummit-discuss] [TECH TOPIC] Signature management - keys, modules, firmware, was: Last minute nominations: mcgrof and toshi

[Jason Cooper]

Hi Linus,

On Wed, Aug 03, 2016 at 12:41:00PM +0200, Linus Walleij wrote:
> On Wed, Aug 3, 2016 at 12:28 PM, Jani Nikula <jani.nikula@intel.com> wrote:
> > On Wed, 03 Aug 2016, Linus Walleij <linus.walleij@linaro.org> wrote:
> 
> >> I would trust an Intel WiFi driver if it was signed by Dirk Hohndel
> >> or H. Peter Anvin whose GPG keys I have in my own web of trust
> >> and work for Intel. And this is simply because I trust these guys
> >> more than the corporate entity they work for.
> >
> > I think you're conflating the trust you have in someone or something
> > actually being who they claim they are with the trust you have in
> > them. The GPG keys are used for the former, and it's *relatively* easy
> > to achieve by key signing events and web of trust. The latter is much
> > harder, and involves all the things you usually have to do to gain trust
> > in people.
> >
> > I would imagine we'd want to ensure the firmware blobs actually come
> > from whoever writes them. I would imagine this would be the company. I
> > don't think the signatures per se should imply a guarantee of quality,
> > just that the firmware originates from where it's supposed to originate.
> >
> > If you insist the individuals you trust sign the blobs, I think you're
> > putting them under pressure to scrutinize the contents, while they might
> > not be in a position to do so, like James says.
> 
> Well, that is what we insist that people sending is code does. That is
> what Signed-off-by and the signed pull requests mean isn't it?

Those are small, or at least digestible chunks of code...

And yes, this is the ideal situation we should strive for.

> That we trust the person. GPG is just mechanics to make sure it is
> really that person which we trust.

Agreed.

> As for trusting corporate entities, I understand that I may be
> out-of-the-ordinary anarchist when it comes to that, I can certainly
> live with the fact that everyone else in the world has no problem with
> that and doesn't understand what I'm talking about or why it would
> be a problem. It's just like, my opinion, man.

This is why the word 'trust' is so problematic.  I want to 'verify' that
a blob claiming to be for my iwlwifi card was actually the one shipped
by Intel.  Not because I trust Intel to the same degree I trust David
Woodhouse or other individuals, but because it fails better.

In the event something mysterious is found in the blob, like the recent
UEFI mess [1], I don't have to guess wether it was injected into my
machine, or put there by the manufacturer.  I *know* it came from the
manufacturer.  They signed it.  Now I have someone to blame. :-)

Or, more pragmatically, I can point to the signed blob and say
"Seriously, guys?  You let this out the door?  wtf?"  It's more about
holding individuals/entities accountable for what they ship.

> The point is that the kind of trust technology you choose - certificates
> or GPG signatures - sort of decides and codifies what it is you trust,
> it creates an ontology for this. (I.e. "the world is populated by people
> you can trust" vs "the world is populated by legal entities you can
> trust".) Choosing one or the other is fine, but should be done consciously
> I think.

I don't think it's an either-or scenario.  But I agree it should be a
conscious decision.  I also know that trust is not binary, nor is it
eternal.  Any system that doesn't account for both is doomed to be a
rigid maintenance nightmare.

thx,

Jason.

[1] Basically, they found a function which does nothing but execute code
    at an address controlled by the caller.
    http://blog.cr4.sh/2016/06/exploring-and-exploiting-lenovo.html
     Go to "Bonus 0day", second code block.

Re: [Ksummit-discuss] [TECH TOPIC] Signature management - keys, modules, firmware, was: Last minute nominations: mcgrof and toshi

[Vinod Koul]

On Wed, Aug 03, 2016 at 11:47:26AM +0200, Linus Walleij wrote:
> On Tue, Aug 2, 2016 at 4:13 PM, James Bottomley
> <James.Bottomley@hansenpartnership.com> wrote:
> > On Tue, 2016-08-02 at 14:54 +0200, Linus Walleij wrote:
> 
> >> What I always intuitively felt is that I would be happy if the same
> >> GPG keys we use for pull requests of kernel code would extend
> >> to firmware signing, so that we move from the overall-industry
> >> focus on legislative bodies (Thawte, ...) signing certificates with
> >> OpenSSL and thus being the root of trust, over to putting the root
> >> of trust for any software related to Linux into the same web of
> >> trust that we already use for developing the code per se.
> >
> > This is the vision that Monkeysphere is based on
> >
> > http://web.monkeysphere.info/
> 
> That looks nice.
> 
> >> I would certainly trust a firmware signed by say Laurent Pinchart,
> >> but not sure about one signed by E.Corp.
> >
> > Really?  Assuming E.Corp is the one actually producing the firmware,
> > why would you say they're less qualified than Laurent to certify their
> > own firmware.  Half the SCSI chips I see have proprietary firmware.
> >  Even if I were willing to sign it, would you really trust my signature
> > when I can't even decompile it?
> 
> I would trust an Intel WiFi driver if it was signed by Dirk Hohndel
> or H. Peter Anvin whose GPG keys I have in my own web of trust
> and work for Intel. And this is simply because I trust these guys
> more than the corporate entity they work for.

One more point worth mentioning here...

Whatever solution we decide, some firmware is already signed. Some of
the Intel firmware we submit to linux-firmware is signed and a firmware
with bad or unsigned keys will fail to load on these devices. Now how
much we are willing to trust that is entirely different question.

Any solution needs to comprehend that additional signing might be
present.

And I am ofcourse interested in this discussion :-)

-- 
~Vinod

Re: [Ksummit-discuss] [TECH TOPIC] Signature management - keys, modules, firmware, was: Last minute nominations: mcgrof and toshi

[David Woodhouse]

[-- Attachment #1: Type: text/plain, Size: 657 bytes --]

On Fri, 2016-08-12 at 18:08 +0530, Vinod Koul wrote:
> Any solution needs to comprehend that additional signing might be
> present.

I would go further than that: Any solution needs to be able to *use*
existing signatures. I don't like your use of the term "additional
signing".

It's for that reason that I think we actually want to (hold our noses
and) support Authenticode signatures too. Because some firmware images
we want to use are available with original signatures in that form.

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse@intel.com                              Intel Corporation


[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5760 bytes --]

Re: [Ksummit-discuss] [TECH TOPIC] Signature management - keys, modules, firmware, was: Last minute nominations: mcgrof and toshi

[Andy Lutomirski]

[-- Attachment #1: Type: text/plain, Size: 2244 bytes --]

On Aug 12, 2016 3:30 PM, "Vinod Koul" <vinod.koul@intel.com> wrote:
>
> On Wed, Aug 03, 2016 at 11:47:26AM +0200, Linus Walleij wrote:
> > On Tue, Aug 2, 2016 at 4:13 PM, James Bottomley
> > <James.Bottomley@hansenpartnership.com> wrote:
> > > On Tue, 2016-08-02 at 14:54 +0200, Linus Walleij wrote:
> >
> > >> What I always intuitively felt is that I would be happy if the same
> > >> GPG keys we use for pull requests of kernel code would extend
> > >> to firmware signing, so that we move from the overall-industry
> > >> focus on legislative bodies (Thawte, ...) signing certificates with
> > >> OpenSSL and thus being the root of trust, over to putting the root
> > >> of trust for any software related to Linux into the same web of
> > >> trust that we already use for developing the code per se.
> > >
> > > This is the vision that Monkeysphere is based on
> > >
> > > http://web.monkeysphere.info/
> >
> > That looks nice.
> >
> > >> I would certainly trust a firmware signed by say Laurent Pinchart,
> > >> but not sure about one signed by E.Corp.
> > >
> > > Really?  Assuming E.Corp is the one actually producing the firmware,
> > > why would you say they're less qualified than Laurent to certify their
> > > own firmware.  Half the SCSI chips I see have proprietary firmware.
> > >  Even if I were willing to sign it, would you really trust my
signature
> > > when I can't even decompile it?
> >
> > I would trust an Intel WiFi driver if it was signed by Dirk Hohndel
> > or H. Peter Anvin whose GPG keys I have in my own web of trust
> > and work for Intel. And this is simply because I trust these guys
> > more than the corporate entity they work for.
>
> One more point worth mentioning here...
>
> Whatever solution we decide, some firmware is already signed. Some of
> the Intel firmware we submit to linux-firmware is signed and a firmware
> with bad or unsigned keys will fail to load on these devices. Now how
> much we are willing to trust that is entirely different question.
>
> Any solution needs to comprehend that additional signing might be
> present.

I see device-verified signatures as orthogonal: the kernel loads a blob,
optionally verifies the blob, and that blob just happens to contain a
signature.

--Andy

[-- Attachment #2: Type: text/html, Size: 3023 bytes --]

Re: [Ksummit-discuss] [TECH TOPIC] Signature management - keys, modules, firmware, was: Last minute nominations: mcgrof and toshi

[David Woodhouse]

[-- Attachment #1: Type: text/plain, Size: 1037 bytes --]

On Fri, 2016-08-12 at 05:54 -0700, Andy Lutomirski wrote:
> 
> > Whatever solution we decide, some firmware is already signed. Some of
> > the Intel firmware we submit to linux-firmware is signed and a firmware
> > with bad or unsigned keys will fail to load on these devices. Now how
> > much we are willing to trust that is entirely different question.
> >
> > Any solution needs to comprehend that additional signing might be
> > present.
>
> I see device-verified signatures as orthogonal: the kernel loads a
> blob, optionally verifies the blob, and that blob just happens to
> contain a signature.

To a certain extent yes. If you *know* the device will check the
signature then you might not bother. Then again, this stuff is often
fairly opaque and the device *might* not check for itself in some
circumstances (prototype hardware, debug modes, etc.) so if there *is*
a signature and *if* it isn't just part of an opaque blob, then it
might make some sense to validate it for ourselves too.

-- 
dwmw2



[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5760 bytes --]

Re: [Ksummit-discuss] [TECH TOPIC] Signature management - keys, modules, firmware, was: Last minute nominations: mcgrof and toshi

[Vinod Koul]

On Fri, Aug 12, 2016 at 05:54:25AM -0700, Andy Lutomirski wrote:
> On Aug 12, 2016 3:30 PM, "Vinod Koul" <vinod.koul@intel.com> wrote:
> > One more point worth mentioning here...
> >
> > Whatever solution we decide, some firmware is already signed. Some of
> > the Intel firmware we submit to linux-firmware is signed and a firmware
> > with bad or unsigned keys will fail to load on these devices. Now how
> > much we are willing to trust that is entirely different question.
> >
> > Any solution needs to comprehend that additional signing might be
> > present.
> 
> I see device-verified signatures as orthogonal: the kernel loads a blob,
> optionally verifies the blob, and that blob just happens to contain a
> signature.

In that case we should not optionally verify. But if we trust vendors
sign, we don't need to verify..

-- 
~Vinod

Re: [Ksummit-discuss] [TECH TOPIC] Signature management - keys, modules, firmware, was: Last minute nominations: mcgrof and toshi

[David Howells]

I would want to attend this.

David

Re: [Ksummit-discuss] [TECH TOPIC] Signature management - keys, modules, firmware, was: Last minute nominations: mcgrof and toshi

[Ard Biesheuvel]

On 27 July 2016 at 16:08, David Howells <dhowells@redhat.com> wrote:
> I would want to attend this.
>

So would I

-- 
Ard.

Re: [Ksummit-discuss] [TECH TOPIC] Signature management - keys, modules, firmware, was: Last minute nominations: mcgrof and toshi

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 191 bytes --]

On Wed, Jul 27, 2016 at 04:10:10PM +0200, Ard Biesheuvel wrote:
> On 27 July 2016 at 16:08, David Howells <dhowells@redhat.com> wrote:
> > I would want to attend this.

> So would I

Me too.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi

[James Bottomley]

[-- Attachment #1: Type: text/plain, Size: 4622 bytes --]

On Tue, 2016-07-26 at 15:42 +0100, David Woodhouse wrote:
> On Sat, 2016-07-16 at 01:52 +0100, Mark Brown wrote:
> > On Fri, Jul 15, 2016 at 03:57:51PM -0400, Mimi Zohar wrote:
> > 
> > > Oops, "Signature management - keys, modules, firmware" was a
> > > suggestion
> > > from last year, but in my opinion still very apropos.
> > 
> > Yup, definitely - especially with secure boot starting to firm up 
> > on the ARM side there's a bunch more interest in it from more 
> > embedded applications.
> 
> Are we going to propose this again "formally" (i.e. sufficiently
> clearly that the committee take note and consider it)?

Heh, we've got lots of people wanting to participate, but no-one really
wanting to make the proposal, so I'll try.

internal kernel key management is becoming a bit of an uncontrolled
mess.  We have several sources of trusted keys: the secure boot keyring
(called the db database), the internal keys the kernel was compiled
with, keys in the TPM which are declared to the kernel (this is another
whole world of pain because adding this damaged the current TPM key
management infrastructure from userspace), IMA keys (used for file
integrity measurement), authentication and encryption keys (things like
keys used to encrypt the disk, authenticate NFS roots etc).

There are several issues

   1. Population and update policy: How should we populate the default
      keyrings and revocation lists?  Should we have a built in list of
      absolute trust that can never be added to? I think the current
      default here is OK: it's populate with the kernel built in keys and
      nothing else.  If userspace wants to populate with, say, the secure
      boot keys, then it can do so from init.  An issue here is the
      Microsoft signing key, which most Linux people have but which they
      wouldn't necessarily consider to be a source of absolute trust. 
       However, third party driver vendors would like a way to get their
      key trusted by the kernel so they can easily supply modules (This
      isn't a binary module issue: the code is usually GPL, but the
      vendors would like to supply updates asynchronously to the distro
      release cycle).  We can say their key should be added as part of the
      rpm that installs the module, but do users really want this key
      adding to the default keyring to be trusted for non-module
      operations?
   2. Virtualization of the keyrings.  The issue here is that you don't
      necessarily want root in a container to have full access to the
      kernel keyrings.  It looks to me like we can use a simple per
      namespace virtualization of the key permissions, but I don't think
      this should be a topic of discussion before it has been proposed and
      discussed on the containers list (which no-one has done yet, in
      spite of my requesting).
   3. Integration with existing key management infrastructures.  The issue
      here is things like the gnome keyring and the TPM.  The TPM is a
      particularly thorny problem: as a key store, the TPM has a very
      limited storage space, so something has effectively to swap keys in
      and out as they're used.  This function is currently performed by a
      userspace stack called the TSS.  However, the kernel use of the TPM
      effectively steals the nvram resource behind the manager's back and
      can lead to resource starvation issues in the TPM and unexpected
      responses back to the user space TSS.  If the kernel wants to use
      TPM keys, it needs either to request them properly from the TSS or
      we need to pull TPM key management fully into the kernel and make
      the TSS use it.
   4. Our current key type model is slightly confusing, because we have
      about 18 different ones from specific key types: assymetric, secure,
      encrypted confused with use case key types like: cifs.spnego,
      dns_resolver and grouping types like keyring.  We should probably
      document them all somewhere and encourage subsystems which don't use
      them (like dm crypt) to start.  We might also consider discouraging
      key type proliferation?
   5. root (uid 0) access: should root be able to modify any keyring?

Probably a ton more issues I forgot, but others can add them.  A
precursor to this discussion should probably be an introductory
presentation about how this all currently works.  If you can't answer
the question how do I add a key to the kernel for a signed module, you
need the introductory session ...

James

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5100 bytes --]

Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi

[Johannes Berg]

On Wed, 2016-07-27 at 11:06 -0400, James Bottomley wrote:
> On Tue, 2016-07-26 at 15:42 +0100, David Woodhouse wrote:
> > On Sat, 2016-07-16 at 01:52 +0100, Mark Brown wrote:
> > > On Fri, Jul 15, 2016 at 03:57:51PM -0400, Mimi Zohar wrote:
> > > 
> > > > Oops, "Signature management - keys, modules, firmware" was a
> > > > suggestion
> > > > from last year, but in my opinion still very apropos.
> > > 
> > > Yup, definitely - especially with secure boot starting to firm
> > > up 
> > > on the ARM side there's a bunch more interest in it from more 
> > > embedded applications.
> > 
> > Are we going to propose this again "formally" (i.e. sufficiently
> > clearly that the committee take note and consider it)?
> 
> Heh, we've got lots of people wanting to participate, but no-one
> really
> wanting to make the proposal, so I'll try.
> 
> internal kernel key management is becoming a bit of an uncontrolled
> mess.  We have several sources of trusted keys: the secure boot
> keyring
> (called the db database), the internal keys the kernel was compiled
> with, keys in the TPM which are declared to the kernel (this is
> another
> whole world of pain because adding this damaged the current TPM key
> management infrastructure from userspace), IMA keys (used for file
> integrity measurement), authentication and encryption keys (things
> like
> keys used to encrypt the disk, authenticate NFS roots etc).
> 
> There are several issues
> 
>    1. Population and update policy: How should we populate the
> default
>       keyrings and revocation lists?  Should we have a built in list
> of
>       absolute trust that can never be added to? I think the current
>       default here is OK: it's populate with the kernel built in keys
> and
>       nothing else.  If userspace wants to populate with, say, the
> secure
>       boot keys, then it can do so from init.  An issue here is the
>       Microsoft signing key, which most Linux people have but which
> they
>       wouldn't necessarily consider to be a source of absolute
> trust. 
>        However, third party driver vendors would like a way to get
> their
>       key trusted by the kernel so they can easily supply modules
> (This
>       isn't a binary module issue: the code is usually GPL, but the
>       vendors would like to supply updates asynchronously to the
> distro
>       release cycle).  We can say their key should be added as part
> of the
>       rpm that installs the module, but do users really want this key
>       adding to the default keyring to be trusted for non-module
>       operations?
>    2. Virtualization of the keyrings.  The issue here is that you
> don't
>       necessarily want root in a container to have full access to the
>       kernel keyrings.  It looks to me like we can use a simple per
>       namespace virtualization of the key permissions, but I don't
> think
>       this should be a topic of discussion before it has been
> proposed and
>       discussed on the containers list (which no-one has done yet, in
>       spite of my requesting).
>    3. Integration with existing key management infrastructures.  The
> issue
>       here is things like the gnome keyring and the TPM.  The TPM is
> a
>       particularly thorny problem: as a key store, the TPM has a very
>       limited storage space, so something has effectively to swap
> keys in
>       and out as they're used.  This function is currently performed
> by a
>       userspace stack called the TSS.  However, the kernel use of the
> TPM
>       effectively steals the nvram resource behind the manager's back
> and
>       can lead to resource starvation issues in the TPM and
> unexpected
>       responses back to the user space TSS.  If the kernel wants to
> use
>       TPM keys, it needs either to request them properly from the TSS
> or
>       we need to pull TPM key management fully into the kernel and
> make
>       the TSS use it.
>    4. Our current key type model is slightly confusing, because we
> have
>       about 18 different ones from specific key types: assymetric,
> secure,
>       encrypted confused with use case key types like: cifs.spnego,
>       dns_resolver and grouping types like keyring.  We should
> probably
>       document them all somewhere and encourage subsystems which
> don't use
>       them (like dm crypt) to start.  We might also consider
> discouraging
>       key type proliferation?
>    5. root (uid 0) access: should root be able to modify any keyring?
> 
> Probably a ton more issues I forgot, but others can add them.

Seems like the "signed firmware" thing should show up somewhere here.

I have an interest in that because I finally want to remove the crufty
crda etc. implementation for the wireless regulatory database and just
load a (signed) file containing the entire database (which fits in at
<4k, so size isn't an issue).

johannes

Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi

[David Howells]

James Bottomley <James.Bottomley@HansenPartnership.com> wrote:

>    3. Integration with existing key management infrastructures.  The issue
>       here is things like the gnome keyring and the TPM.  The TPM is a
>       particularly thorny problem: as a key store, the TPM has a very
>       limited storage space, so something has effectively to swap keys in
>       and out as they're used.  This function is currently performed by a
>       userspace stack called the TSS.  However, the kernel use of the TPM
>       effectively steals the nvram resource behind the manager's back and
>       can lead to resource starvation issues in the TPM and unexpected
>       responses back to the user space TSS.  If the kernel wants to use
>       TPM keys, it needs either to request them properly from the TSS or
>       we need to pull TPM key management fully into the kernel and make
>       the TSS use it.

I have partial patches for this, but they're against an old, pre-tpm2 version
of the kernel and need updating.  They expose TPM keys as a subtype of the
asymmetric key type.

David

Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi

[James Bottomley]

On Wed, 2016-07-27 at 16:37 +0100, David Howells wrote:
> James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
> 
> >    3. Integration with existing key management infrastructures.  The issue
> >       here is things like the gnome keyring and the TPM.  The TPM is a
> >       particularly thorny problem: as a key store, the TPM has a very
> >       limited storage space, so something has effectively to swap keys in
> >       and out as they're used.  This function is currently performed by a
> >       userspace stack called the TSS.  However, the kernel use of the TPM
> >       effectively steals the nvram resource behind the manager's back and
> >       can lead to resource starvation issues in the TPM and unexpected
> >       responses back to the user space TSS.  If the kernel wants to use
> >       TPM keys, it needs either to request them properly from the TSS or
> >       we need to pull TPM key management fully into the kernel and make
> >       the TSS use it.
> 
> I have partial patches for this, but they're against an old, pre-tpm2 version
> of the kernel and need updating.  They expose TPM keys as a subtype of the
> asymmetric key type.

Heh, you really know how to poke a sore spot, since we effectively have
two TSSs in Linux: trousers the TPM 1.1 and 1.2 compatible one and
ibmtpm20tss for TPM 2.0.  I don't think we have an answer on how we
make them work compatibly.  I'm sort of hoping to get some coherence in
the TPM Microconference at Plumbers

http://www.linuxplumbersconf.org/2016/ocw/events/LPC2016/tracks/585

However, if we do an upcall to the TSS, then we can't use TPM keys in
the pre-boot and have difficulty using them in initrd environments,
which seems like it might cause problems.

James

Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi

[Andy Lutomirski]

On Wed, Jul 27, 2016 at 9:14 AM, James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
> On Wed, 2016-07-27 at 16:37 +0100, David Howells wrote:
>> James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
>>
>> >    3. Integration with existing key management infrastructures.  The issue
>> >       here is things like the gnome keyring and the TPM.  The TPM is a
>> >       particularly thorny problem: as a key store, the TPM has a very
>> >       limited storage space, so something has effectively to swap keys in
>> >       and out as they're used.  This function is currently performed by a
>> >       userspace stack called the TSS.  However, the kernel use of the TPM
>> >       effectively steals the nvram resource behind the manager's back and
>> >       can lead to resource starvation issues in the TPM and unexpected
>> >       responses back to the user space TSS.  If the kernel wants to use
>> >       TPM keys, it needs either to request them properly from the TSS or
>> >       we need to pull TPM key management fully into the kernel and make
>> >       the TSS use it.
>>
>> I have partial patches for this, but they're against an old, pre-tpm2 version
>> of the kernel and need updating.  They expose TPM keys as a subtype of the
>> asymmetric key type.
>
> Heh, you really know how to poke a sore spot, since we effectively have
> two TSSs in Linux: trousers the TPM 1.1 and 1.2 compatible one and
> ibmtpm20tss for TPM 2.0.  I don't think we have an answer on how we
> make them work compatibly.  I'm sort of hoping to get some coherence in
> the TPM Microconference at Plumbers
>
> http://www.linuxplumbersconf.org/2016/ocw/events/LPC2016/tracks/585
>
> However, if we do an upcall to the TSS, then we can't use TPM keys in
> the pre-boot and have difficulty using them in initrd environments,
> which seems like it might cause problems.
>

I think this nuts.  The kernel should arbitrate use of the TPM's key
slots and handle context switching.  Doing it in userspace is a
terrible idea for this and other reasons.

--Andy

Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi

[James Bottomley]

On Wed, 2016-07-27 at 10:57 -0700, Andy Lutomirski wrote:
> On Wed, Jul 27, 2016 at 9:14 AM, James Bottomley
> <James.Bottomley@hansenpartnership.com> wrote:
> > On Wed, 2016-07-27 at 16:37 +0100, David Howells wrote:
> > > James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
> > > 
> > > >    3. Integration with existing key management infrastructures.
> > > >   The issue
> > > >       here is things like the gnome keyring and the TPM.  The
> > > > TPM is a
> > > >       particularly thorny problem: as a key store, the TPM has
> > > > a very
> > > >       limited storage space, so something has effectively to
> > > > swap keys in
> > > >       and out as they're used.  This function is currently
> > > > performed by a
> > > >       userspace stack called the TSS.  However, the kernel use
> > > > of the TPM
> > > >       effectively steals the nvram resource behind the
> > > > manager's back and
> > > >       can lead to resource starvation issues in the TPM and
> > > > unexpected
> > > >       responses back to the user space TSS.  If the kernel
> > > > wants to use
> > > >       TPM keys, it needs either to request them properly from
> > > > the TSS or
> > > >       we need to pull TPM key management fully into the kernel
> > > > and make
> > > >       the TSS use it.
> > > 
> > > I have partial patches for this, but they're against an old, pre
> > > -tpm2 version
> > > of the kernel and need updating.  They expose TPM keys as a
> > > subtype of the
> > > asymmetric key type.
> > 
> > Heh, you really know how to poke a sore spot, since we effectively
> > have
> > two TSSs in Linux: trousers the TPM 1.1 and 1.2 compatible one and
> > ibmtpm20tss for TPM 2.0.  I don't think we have an answer on how we
> > make them work compatibly.  I'm sort of hoping to get some
> > coherence in
> > the TPM Microconference at Plumbers
> > 
> > http://www.linuxplumbersconf.org/2016/ocw/events/LPC2016/tracks/585
> > 
> > However, if we do an upcall to the TSS, then we can't use TPM keys
> > in
> > the pre-boot and have difficulty using them in initrd environments,
> > which seems like it might cause problems.
> > 
> 
> I think this nuts.  The kernel should arbitrate use of the TPM's key
> slots and handle context switching.  Doing it in userspace is a
> terrible idea for this and other reasons.

Hey, I don't disagree, but the user space TSS would have to be updated
as well if we did this.  Right at the moment, the tpmd in the kernel is
a straight TPM command pass through.  We'd need a more complex
interface if the kernel is actually going to manage TPM key slots.  I
think it means quite a big code change, both in the kernel and for the
new interface and for the TSS.

Anyway, I put it on the proposed agenda for the Plumbers TPM
discussions:

http://wiki.linuxplumbersconf.org/2016:tpms

James

Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi

[Andy Lutomirski]

On Wed, Jul 27, 2016 at 12:00 PM, James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
> On Wed, 2016-07-27 at 10:57 -0700, Andy Lutomirski wrote:
>> On Wed, Jul 27, 2016 at 9:14 AM, James Bottomley
>> <James.Bottomley@hansenpartnership.com> wrote:
>> > On Wed, 2016-07-27 at 16:37 +0100, David Howells wrote:
>> > > James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
>> > >
>> > > >    3. Integration with existing key management infrastructures.
>> > > >   The issue
>> > > >       here is things like the gnome keyring and the TPM.  The
>> > > > TPM is a
>> > > >       particularly thorny problem: as a key store, the TPM has
>> > > > a very
>> > > >       limited storage space, so something has effectively to
>> > > > swap keys in
>> > > >       and out as they're used.  This function is currently
>> > > > performed by a
>> > > >       userspace stack called the TSS.  However, the kernel use
>> > > > of the TPM
>> > > >       effectively steals the nvram resource behind the
>> > > > manager's back and
>> > > >       can lead to resource starvation issues in the TPM and
>> > > > unexpected
>> > > >       responses back to the user space TSS.  If the kernel
>> > > > wants to use
>> > > >       TPM keys, it needs either to request them properly from
>> > > > the TSS or
>> > > >       we need to pull TPM key management fully into the kernel
>> > > > and make
>> > > >       the TSS use it.
>> > >
>> > > I have partial patches for this, but they're against an old, pre
>> > > -tpm2 version
>> > > of the kernel and need updating.  They expose TPM keys as a
>> > > subtype of the
>> > > asymmetric key type.
>> >
>> > Heh, you really know how to poke a sore spot, since we effectively
>> > have
>> > two TSSs in Linux: trousers the TPM 1.1 and 1.2 compatible one and
>> > ibmtpm20tss for TPM 2.0.  I don't think we have an answer on how we
>> > make them work compatibly.  I'm sort of hoping to get some
>> > coherence in
>> > the TPM Microconference at Plumbers
>> >
>> > http://www.linuxplumbersconf.org/2016/ocw/events/LPC2016/tracks/585
>> >
>> > However, if we do an upcall to the TSS, then we can't use TPM keys
>> > in
>> > the pre-boot and have difficulty using them in initrd environments,
>> > which seems like it might cause problems.
>> >
>>
>> I think this nuts.  The kernel should arbitrate use of the TPM's key
>> slots and handle context switching.  Doing it in userspace is a
>> terrible idea for this and other reasons.
>
> Hey, I don't disagree, but the user space TSS would have to be updated
> as well if we did this.  Right at the moment, the tpmd in the kernel is
> a straight TPM command pass through.  We'd need a more complex
> interface if the kernel is actually going to manage TPM key slots.  I
> think it means quite a big code change, both in the kernel and for the
> new interface and for the TSS.

I admit it's been a while since I read the TPM protocol specs, but I
think it might be doable without breaking compatibility.  We could
pretend to pass commands through but instead either emulate a TPM with
a whole lot of slots or emulate a TPM with somewhat fewer slots than
the real one and remap the slot numbering as needed.

>
> Anyway, I put it on the proposed agenda for the Plumbers TPM
> discussions:
>
> http://wiki.linuxplumbersconf.org/2016:tpms

If I manage to still be in town, I'll try to make it to that session.

--Andy

Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi

[James Bottomley]

On Wed, 2016-07-27 at 12:20 -0700, Andy Lutomirski wrote:
> On Wed, Jul 27, 2016 at 12:00 PM, James Bottomley
> <James.Bottomley@hansenpartnership.com> wrote:
> > On Wed, 2016-07-27 at 10:57 -0700, Andy Lutomirski wrote:
> > > On Wed, Jul 27, 2016 at 9:14 AM, James Bottomley
> > > <James.Bottomley@hansenpartnership.com> wrote:
> > > > On Wed, 2016-07-27 at 16:37 +0100, David Howells wrote:
> > > > > James Bottomley <James.Bottomley@HansenPartnership.com>
> > > > > wrote:
> > > > > 
> > > > > >    3. Integration with existing key management
> > > > > > infrastructures.
> > > > > >   The issue
> > > > > >       here is things like the gnome keyring and the TPM. 
> > > > > >  The
> > > > > > TPM is a
> > > > > >       particularly thorny problem: as a key store, the TPM
> > > > > > has
> > > > > > a very
> > > > > >       limited storage space, so something has effectively
> > > > > > to
> > > > > > swap keys in
> > > > > >       and out as they're used.  This function is currently
> > > > > > performed by a
> > > > > >       userspace stack called the TSS.  However, the kernel
> > > > > > use
> > > > > > of the TPM
> > > > > >       effectively steals the nvram resource behind the
> > > > > > manager's back and
> > > > > >       can lead to resource starvation issues in the TPM and
> > > > > > unexpected
> > > > > >       responses back to the user space TSS.  If the kernel
> > > > > > wants to use
> > > > > >       TPM keys, it needs either to request them properly
> > > > > > from
> > > > > > the TSS or
> > > > > >       we need to pull TPM key management fully into the
> > > > > > kernel
> > > > > > and make
> > > > > >       the TSS use it.
> > > > > 
> > > > > I have partial patches for this, but they're against an old, 
> > > > > pre-tpm2 version of the kernel and need updating.  They 
> > > > > expose TPM keys as a subtype of the asymmetric key type.
> > > > 
> > > > Heh, you really know how to poke a sore spot, since we 
> > > > effectively have two TSSs in Linux: trousers the TPM 1.1 and 
> > > > 1.2 compatible one and ibmtpm20tss for TPM 2.0.  I don't think 
> > > > we have an answer on how we make them work compatibly.  I'm 
> > > > sort of hoping to get some coherence in the TPM Microconference
> > > > at Plumbers
> > > > 
> > > > http://www.linuxplumbersconf.org/2016/ocw/events/LPC2016/tracks
> > > > /585
> > > > 
> > > > However, if we do an upcall to the TSS, then we can't use TPM 
> > > > keys in the pre-boot and have difficulty using them in initrd
> > > > environments, which seems like it might cause problems.
> > > > 
> > > 
> > > I think this nuts.  The kernel should arbitrate use of the TPM's 
> > > key slots and handle context switching.  Doing it in userspace is 
> > > a terrible idea for this and other reasons. 
> > 
> > Hey, I don't disagree, but the user space TSS would have to be 
> > updated as well if we did this.  Right at the moment, the tpmd in 
> > the kernel is a straight TPM command pass through.  We'd need a 
> > more complex interface if the kernel is actually going to manage 
> > TPM key slots.   I think it means quite a big code change, both in 
> > the kernel and for the new interface and for the TSS.
> 
> I admit it's been a while since I read the TPM protocol specs, but I
> think it might be doable without breaking compatibility.  We could
> pretend to pass commands through but instead either emulate a TPM 
> with a whole lot of slots or emulate a TPM with somewhat fewer slots 
> than the real one and remap the slot numbering as needed.

Been there, done that, got the flashing bow tie from our TPM experts as
a "here's a shiny thing small kernel person, you play with it while we
solve the hard security problems" prize.

The reason it doesn't work as simply is that TPM commands mostly
require authentication and may be encrypted (transport wrapped in TPM
speak).  For commands which manipulate keys, the key handle may be part
of the HMAC authentication verifier, so we can't simply replace the key
handle without the HMAC failing to verify or they're encrypted, in
which case we can't even see what the handle is.  The reason the TSS
can do this is that it generates the HMAC and even the wrapping.  It's
hard to see how to solve this without either pulling the whole TSS into
the kernel (yuk) or having a sideband API where the kernel and the TSS
co-operate on key slot handling.

> > Anyway, I put it on the proposed agenda for the Plumbers TPM
> > discussions:
> > 
> > http://wiki.linuxplumbersconf.org/2016:tpms
> 
> If I manage to still be in town, I'll try to make it to that session.

Great, thanks!

James


> --Andy
> _______________________________________________
> Ksummit-discuss mailing list
> Ksummit-discuss@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
> 

Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi

[David Howells]

James Bottomley <James.Bottomley@HansenPartnership.com> wrote:

>    4. Our current key type model is slightly confusing, because we have
>       about 18 different ones from specific key types: assymetric, secure,

"secure"?  Do you mean "trusted"?

>       encrypted confused with use case key types like: cifs.spnego,
>       dns_resolver and grouping types like keyring.  We should probably
>       document them all somewhere and encourage subsystems which don't use
>       them (like dm crypt) to start.  We might also consider discouraging
>       key type proliferation?

With hindsight, one thing I should've done right from the start is to search
*only* on key description and not key type plus key description.  It might be
too impractical to change that now - though it could be made possible to pass
NULL as the type to keyring_search().  There are problems with doing this:

 (1) The keyring associative array is indexed by key type and key description
     for fastest access (the entire array can also be iterated over to find
     things by other criteria).  Changing this affects the performance of
     anything that wants to look up specifically by type+description, though
     in actuality it might not be a problem.

 (2) Currently we don't permit two keys with the same type+description to be
     in a keyring (adding one displaces the other).  If we look up only by
     desc, we really need to tighten the restriction to require that keys must
     differ on description, irrespective of type.  Note that this restriction
     is a function of the assoc array.

Take AF_RXRPC and kafs as an example: they don't really want an rxrpc-type
key, what they really want is a key that represents an old AFS KA service
token, a kerberos 4/5 ticket or a gss token.  The advantage of having an
rxrpc-type key is that I get to parse the token at key instantiation time
rather than each time I request it or want to use it.

With something like a kerberos ticket, it would likely be possible to extract
the relevant fields without knowledge of what it's going to be used for.

Another advantage of using the kerberos ticket key directly, is that it might
make it possible to share with the in-keyring cache available to libkrb5.

David

Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi

[James Bottomley]

On Wed, 2016-07-27 at 17:07 +0100, David Howells wrote:
> James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
> 
> >    4. Our current key type model is slightly confusing, because we have
> >       about 18 different ones from specific key types: assymetric, secure,
> 
> "secure"?  Do you mean "trusted"?

Yes, sorry I meant the trusted key types that currently use the TPM.

> >       encrypted confused with use case key types like: cifs.spnego,
> >       dns_resolver and grouping types like keyring.  We should probably
> >       document them all somewhere and encourage subsystems which don't use
> >       them (like dm crypt) to start.  We might also consider discouraging
> >       key type proliferation?
> 
> With hindsight, one thing I should've done right from the start is to search
> *only* on key description and not key type plus key description.  It might be
> too impractical to change that now - though it could be made possible to pass
> NULL as the type to keyring_search().  There are problems with doing this:

OK, can we do this now? because with this change we can look for the
key we actually want to use without knowing its mechanism, which is
kind of the point of keys, particularly asymmetric vs trusted keys
where they're an identical type of key, just one is implemented in
software and the other in the TPM hardware.

>  (1) The keyring associative array is indexed by key type and key description
>      for fastest access (the entire array can also be iterated over to find
>      things by other criteria).  Changing this affects the performance of
>      anything that wants to look up specifically by type+description, though
>      in actuality it might not be a problem.
> 
>  (2) Currently we don't permit two keys with the same type+description to be
>      in a keyring (adding one displaces the other).  If we look up only by
>      desc, we really need to tighten the restriction to require that keys must
>      differ on description, irrespective of type.  Note that this restriction
>      is a function of the assoc array.
> 
> Take AF_RXRPC and kafs as an example: they don't really want an rxrpc-type
> key, what they really want is a key that represents an old AFS KA service
> token, a kerberos 4/5 ticket or a gss token.

Right, that's why I find it confusing.  It confuses use case with
actual type.

>   The advantage of having an rxrpc-type key is that I get to parse 
> the token at key instantiation time rather than each time I request it or want to use it.
> 
> With something like a kerberos ticket, it would likely be possible to extract
> the relevant fields without knowledge of what it's going to be used for.
> 
> Another advantage of using the kerberos ticket key directly, is that it might
> make it possible to share with the in-keyring cache available to libkrb5.

OK, I'm no expert on kerberos.  I draw the line at understanding X509
and RSA keys ... purely in order to preserve my sanity, you understand.

James

Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi

[David Howells]

James Bottomley <James.Bottomley@HansenPartnership.com> wrote:

>    5. root (uid 0) access: should root be able to modify any keyring?

Currently, it's not even allowed to *see* any key or keyring that it doesn't
have permissions to access.  Note that the permissions system doesn't
distinguish between keyrings and other key types.

David

Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi

[David Howells]

James Bottomley <James.Bottomley@HansenPartnership.com> wrote:

>    1. Population and update policy: How should we populate the default
>       keyrings and revocation lists?  Should we have a built in list of
>       absolute trust that can never be added to? I think the current
>       default here is OK: it's populate with the kernel built in keys and
>       nothing else.  If userspace wants to populate with, say, the secure
>       boot keys, then it can do so from init.  An issue here is the
>       Microsoft signing key, which most Linux people have but which they
>       wouldn't necessarily consider to be a source of absolute trust. 
>        However, third party driver vendors would like a way to get their
>       key trusted by the kernel so they can easily supply modules (This
>       isn't a binary module issue: the code is usually GPL, but the
>       vendors would like to supply updates asynchronously to the distro
>       release cycle).  We can say their key should be added as part of the
>       rpm that installs the module, but do users really want this key
>       adding to the default keyring to be trusted for non-module
>       operations?

I have patches that allow the UEFI key and blacklist databases to add to the
kernel keyrings during boot.

We don't want to permit loading a key from a file once the kernel is booted
unless that key is signed by a key already in the keyrings.

David

Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi

[James Bottomley]

On Wed, 2016-07-27 at 17:14 +0100, David Howells wrote:
> James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
> 
> >    1. Population and update policy: How should we populate the default
> >       keyrings and revocation lists?  Should we have a built in list of
> >       absolute trust that can never be added to? I think the current
> >       default here is OK: it's populate with the kernel built in keys and
> >       nothing else.  If userspace wants to populate with, say, the secure
> >       boot keys, then it can do so from init.  An issue here is the
> >       Microsoft signing key, which most Linux people have but which they
> >       wouldn't necessarily consider to be a source of absolute trust. 
> >        However, third party driver vendors would like a way to get their
> >       key trusted by the kernel so they can easily supply modules (This
> >       isn't a binary module issue: the code is usually GPL, but the
> >       vendors would like to supply updates asynchronously to the distro
> >       release cycle).  We can say their key should be added as part of the
> >       rpm that installs the module, but do users really want this key
> >       adding to the default keyring to be trusted for non-module
> >       operations?
> 
> I have patches that allow the UEFI key and blacklist databases to add to the
> kernel keyrings during boot.
> 
> We don't want to permit loading a key from a file once the kernel is booted
> unless that key is signed by a key already in the keyrings.

This is a policy discussion we should have.  If you populate the
immutable .builtin_trusted_keys keyring with the secure boot keys, most
people will end up with a Microsoft key in their keyring (and possibly
even some random motherboard vendor ODM key) which they can't remove. 
 I thought the idea was to use the .secondary_trusted_keys keyring
which is mutable?  That way we can have policy in userspace select
which secure boot keys we might like to trust.

James

Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi

[James Bottomley]

On Wed, 2016-07-27 at 12:28 -0400, James Bottomley wrote:
> On Wed, 2016-07-27 at 17:14 +0100, David Howells wrote:
> > James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
> > 
> > >    1. Population and update policy: How should we populate the default
> > >       keyrings and revocation lists?  Should we have a built in list of
> > >       absolute trust that can never be added to? I think the current
> > >       default here is OK: it's populate with the kernel built in keys and
> > >       nothing else.  If userspace wants to populate with, say, the secure
> > >       boot keys, then it can do so from init.  An issue here is the
> > >       Microsoft signing key, which most Linux people have but which they
> > >       wouldn't necessarily consider to be a source of absolute trust. 
> > >        However, third party driver vendors would like a way to get their
> > >       key trusted by the kernel so they can easily supply modules (This
> > >       isn't a binary module issue: the code is usually GPL, but the
> > >       vendors would like to supply updates asynchronously to the distro
> > >       release cycle).  We can say their key should be added as part of the
> > >       rpm that installs the module, but do users really want this key
> > >       adding to the default keyring to be trusted for non-module
> > >       operations?
> > 
> > I have patches that allow the UEFI key and blacklist databases to 
> > add to the kernel keyrings during boot.
> > 
> > We don't want to permit loading a key from a file once the kernel 
> > is booted unless that key is signed by a key already in the
> > keyrings.
> 
> This is a policy discussion we should have.  If you populate the
> immutable .builtin_trusted_keys keyring with the secure boot keys, 
> most people will end up with a Microsoft key in their keyring (and
> possibly even some random motherboard vendor ODM key) which they 
> can't remove.  I thought the idea was to use the 
> .secondary_trusted_keys keyring which is mutable?  That way we can 
> have policy in userspace select which secure boot keys we might like
> to trust.

As an aside to the aside, perhaps we want the .builtin_trusted_keys to
be mutable up to the point the kernel finishes init and then immutable
after.  That would allow us to update it from the initrd if the
composition of the secure boot keys was in question.

James

Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi

[Luis R. Rodriguez]

On Wed, Jul 27, 2016 at 12:36:07PM -0400, James Bottomley wrote:
> On Wed, 2016-07-27 at 12:28 -0400, James Bottomley wrote:
> > On Wed, 2016-07-27 at 17:14 +0100, David Howells wrote:
> > > James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
> > > 
> > > >    1. Population and update policy: How should we populate the default
> > > >       keyrings and revocation lists?  Should we have a built in list of
> > > >       absolute trust that can never be added to? I think the current
> > > >       default here is OK: it's populate with the kernel built in keys and
> > > >       nothing else.  If userspace wants to populate with, say, the secure
> > > >       boot keys, then it can do so from init.  An issue here is the
> > > >       Microsoft signing key, which most Linux people have but which they
> > > >       wouldn't necessarily consider to be a source of absolute trust. 
> > > >        However, third party driver vendors would like a way to get their
> > > >       key trusted by the kernel so they can easily supply modules (This
> > > >       isn't a binary module issue: the code is usually GPL, but the
> > > >       vendors would like to supply updates asynchronously to the distro
> > > >       release cycle).  We can say their key should be added as part of the
> > > >       rpm that installs the module, but do users really want this key
> > > >       adding to the default keyring to be trusted for non-module
> > > >       operations?
> > > 
> > > I have patches that allow the UEFI key and blacklist databases to 
> > > add to the kernel keyrings during boot.
> > > 
> > > We don't want to permit loading a key from a file once the kernel 
> > > is booted unless that key is signed by a key already in the
> > > keyrings.
> > 
> > This is a policy discussion we should have.  If you populate the
> > immutable .builtin_trusted_keys keyring with the secure boot keys, 
> > most people will end up with a Microsoft key in their keyring (and
> > possibly even some random motherboard vendor ODM key) which they 
> > can't remove.  I thought the idea was to use the 
> > .secondary_trusted_keys keyring which is mutable?  That way we can 
> > have policy in userspace select which secure boot keys we might like
> > to trust.
> 
> As an aside to the aside, perhaps we want the .builtin_trusted_keys to
> be mutable up to the point the kernel finishes init and then immutable
> after.  That would allow us to update it from the initrd if the
> composition of the secure boot keys was in question.

Are you aware of other similar uses before ?

  Luis

Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi

[James Bottomley]

On Wed, 2016-07-27 at 19:20 +0200, Luis R. Rodriguez wrote:
> On Wed, Jul 27, 2016 at 12:36:07PM -0400, James Bottomley wrote:
> > On Wed, 2016-07-27 at 12:28 -0400, James Bottomley wrote:
> > > On Wed, 2016-07-27 at 17:14 +0100, David Howells wrote:
> > > > James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
> > > > 
> > > > >    1. Population and update policy: How should we populate
> > > > > the default
> > > > >       keyrings and revocation lists?  Should we have a built
> > > > > in list of
> > > > >       absolute trust that can never be added to? I think the
> > > > > current
> > > > >       default here is OK: it's populate with the kernel built
> > > > > in keys and
> > > > >       nothing else.  If userspace wants to populate with,
> > > > > say, the secure
> > > > >       boot keys, then it can do so from init.  An issue here
> > > > > is the
> > > > >       Microsoft signing key, which most Linux people have but
> > > > > which they
> > > > >       wouldn't necessarily consider to be a source of
> > > > > absolute trust. 
> > > > >        However, third party driver vendors would like a way
> > > > > to get their
> > > > >       key trusted by the kernel so they can easily supply
> > > > > modules (This
> > > > >       isn't a binary module issue: the code is usually GPL,
> > > > > but the
> > > > >       vendors would like to supply updates asynchronously to
> > > > > the distro
> > > > >       release cycle).  We can say their key should be added
> > > > > as part of the
> > > > >       rpm that installs the module, but do users really want
> > > > > this key
> > > > >       adding to the default keyring to be trusted for non
> > > > > -module
> > > > >       operations?
> > > > 
> > > > I have patches that allow the UEFI key and blacklist databases 
> > > > to add to the kernel keyrings during boot.
> > > > 
> > > > We don't want to permit loading a key from a file once the 
> > > > kernel is booted unless that key is signed by a key already in 
> > > > the keyrings.
> > > 
> > > This is a policy discussion we should have.  If you populate the
> > > immutable .builtin_trusted_keys keyring with the secure boot 
> > > keys, most people will end up with a Microsoft key in their 
> > > keyring (and possibly even some random motherboard vendor ODM 
> > > key) which they can't remove.  I thought the idea was to use the
> > > .secondary_trusted_keys keyring which is mutable?  That way we 
> > > can have policy in userspace select which secure boot keys we 
> > > might like to trust.
> > 
> > As an aside to the aside, perhaps we want the .builtin_trusted_keys 
> > to be mutable up to the point the kernel finishes init and then
> > immutable after.  That would allow us to update it from the initrd 
> > if the composition of the secure boot keys was in question.
> 
> Are you aware of other similar uses before ?

Similar uses of what?

Runtime immutable but boot time mutable?  Yes, it's the UEFI variable
lock protocol.

Not wanting to put Microsoft keys in the immutable trusted keyring? No,
it was just a suspicion based on how I'd feel if my secure boot system
still had a MS key.

James

Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi

[Luis R. Rodriguez]

On Wed, Jul 27, 2016 at 01:51:15PM -0400, James Bottomley wrote:
> On Wed, 2016-07-27 at 19:20 +0200, Luis R. Rodriguez wrote:
> > > As an aside to the aside, perhaps we want the .builtin_trusted_keys 
> > > to be mutable up to the point the kernel finishes init and then
> > > immutable after.  That would allow us to update it from the initrd 
> > > if the composition of the secure boot keys was in question.
> > 
> > Are you aware of other similar uses before ?
> 
> Similar uses of what?
> 
> Runtime immutable but boot time mutable?  Yes, it's the UEFI variable
> lock protocol.
> 
> Not wanting to put Microsoft keys in the immutable trusted keyring? No,
> it was just a suspicion based on how I'd feel if my secure boot system
> still had a MS key.

I'm currently generalizing some APIs for custom section uses, and
this may be one use case to generalize further. If this is done 
per variable rather than per section, that's different though. Of
course we may still want this done per section instead, up to
implementation.

  Luis

Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi

[Mimi Zohar]

On Mi, 2016-07-27 at 12:36 -0400, James Bottomley wrote:
> On Wed, 2016-07-27 at 12:28 -0400, James Bottomley wrote:
> > On Wed, 2016-07-27 at 17:14 +0100, David Howells wrote:
> > > James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
> > > 
> > > >    1. Population and update policy: How should we populate the default
> > > >       keyrings and revocation lists?  Should we have a built in list of
> > > >       absolute trust that can never be added to? I think the current
> > > >       default here is OK: it's populate with the kernel built in keys and
> > > >       nothing else.  If userspace wants to populate with, say, the secure
> > > >       boot keys, then it can do so from init.  An issue here is the
> > > >       Microsoft signing key, which most Linux people have but which they
> > > >       wouldn't necessarily consider to be a source of absolute trust. 
> > > >        However, third party driver vendors would like a way to get their
> > > >       key trusted by the kernel so they can easily supply modules (This
> > > >       isn't a binary module issue: the code is usually GPL, but the
> > > >       vendors would like to supply updates asynchronously to the distro
> > > >       release cycle).  We can say their key should be added as part of the
> > > >       rpm that installs the module, but do users really want this key
> > > >       adding to the default keyring to be trusted for non-module
> > > >       operations?
> > > 
> > > I have patches that allow the UEFI key and blacklist databases to 
> > > add to the kernel keyrings during boot.
> > > 
> > > We don't want to permit loading a key from a file once the kernel 
> > > is booted unless that key is signed by a key already in the
> > > keyrings.
> > 
> > This is a policy discussion we should have.  If you populate the
> > immutable .builtin_trusted_keys keyring with the secure boot keys, 
> > most people will end up with a Microsoft key in their keyring (and
> > possibly even some random motherboard vendor ODM key) which they 
> > can't remove.  I thought the idea was to use the 
> > .secondary_trusted_keys keyring which is mutable?  That way we can 
> > have policy in userspace select which secure boot keys we might like
> > to trust.
> 
> As an aside to the aside, perhaps we want the .builtin_trusted_keys to
> be mutable up to the point the kernel finishes init and then immutable
> after.  That would allow us to update it from the initrd if the
> composition of the secure boot keys was in question.

A lot of work went into making the builtin keyring have only the builtin
kernel keys, that are trusted, because the kernel was signed and
verified.  Even if I trusted a set of keys during boot, different keys
are trusted at different layers for different things.  

For example, the UEFI/shim keys are trusted at the UEFI layer.   If the
UEFI keys are needed once the system is up and running for some reason,
then load them on a separate UEFI keyring.   Allow the host owner to
have the ability to decide whether to trust these keys for verifying
signatures.

I would like to see separate trusted keyrings for firmware, kernel
modules, etc, where only keys signed by a key on the builtin keyring
could be added to them. With Mehmet Kaylaap patch set, additional keys
can be added to the builtin keyring post build.  Those keys are trusted
because the kernel itself is re-signed.

Mimi

Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi

[Andy Lutomirski]

On Wed, Jul 27, 2016 at 12:37 PM, Mimi Zohar <zohar@linux.vnet.ibm.com> wrote:
> On Mi, 2016-07-27 at 12:36 -0400, James Bottomley wrote:
>> On Wed, 2016-07-27 at 12:28 -0400, James Bottomley wrote:
>> > On Wed, 2016-07-27 at 17:14 +0100, David Howells wrote:
>> > > James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
>> > >
>> > > >    1. Population and update policy: How should we populate the default
>> > > >       keyrings and revocation lists?  Should we have a built in list of
>> > > >       absolute trust that can never be added to? I think the current
>> > > >       default here is OK: it's populate with the kernel built in keys and
>> > > >       nothing else.  If userspace wants to populate with, say, the secure
>> > > >       boot keys, then it can do so from init.  An issue here is the
>> > > >       Microsoft signing key, which most Linux people have but which they
>> > > >       wouldn't necessarily consider to be a source of absolute trust.
>> > > >        However, third party driver vendors would like a way to get their
>> > > >       key trusted by the kernel so they can easily supply modules (This
>> > > >       isn't a binary module issue: the code is usually GPL, but the
>> > > >       vendors would like to supply updates asynchronously to the distro
>> > > >       release cycle).  We can say their key should be added as part of the
>> > > >       rpm that installs the module, but do users really want this key
>> > > >       adding to the default keyring to be trusted for non-module
>> > > >       operations?
>> > >
>> > > I have patches that allow the UEFI key and blacklist databases to
>> > > add to the kernel keyrings during boot.
>> > >
>> > > We don't want to permit loading a key from a file once the kernel
>> > > is booted unless that key is signed by a key already in the
>> > > keyrings.
>> >
>> > This is a policy discussion we should have.  If you populate the
>> > immutable .builtin_trusted_keys keyring with the secure boot keys,
>> > most people will end up with a Microsoft key in their keyring (and
>> > possibly even some random motherboard vendor ODM key) which they
>> > can't remove.  I thought the idea was to use the
>> > .secondary_trusted_keys keyring which is mutable?  That way we can
>> > have policy in userspace select which secure boot keys we might like
>> > to trust.
>>
>> As an aside to the aside, perhaps we want the .builtin_trusted_keys to
>> be mutable up to the point the kernel finishes init and then immutable
>> after.  That would allow us to update it from the initrd if the
>> composition of the secure boot keys was in question.
>
> A lot of work went into making the builtin keyring have only the builtin
> kernel keys, that are trusted, because the kernel was signed and
> verified.  Even if I trusted a set of keys during boot, different keys
> are trusted at different layers for different things.
>
> For example, the UEFI/shim keys are trusted at the UEFI layer.   If the
> UEFI keys are needed once the system is up and running for some reason,
> then load them on a separate UEFI keyring.   Allow the host owner to
> have the ability to decide whether to trust these keys for verifying
> signatures.
>
> I would like to see separate trusted keyrings for firmware, kernel
> modules, etc, where only keys signed by a key on the builtin keyring
> could be added to them. With Mehmet Kaylaap patch set, additional keys
> can be added to the builtin keyring post build.  Those keys are trusted
> because the kernel itself is re-signed.

I would like someone to explain why using the keyring mechanism for
this in the first place is a good idea.

As far as I can tell, the design goals of "keys trusted by the kernel
for modules, firmware, etc" are:

 - Keys are added at build time or, according to potentially
system-specific rules, at boot time.

 - Keys should specify what they're trusted *for*.  Some keys should
be trusted to load modules.  Some keys should be trusted to load
specific firmware files.

 - The kernel only knows the public part of these keys, so there's no
particular need to restrict who can see them, who can perform
operations with them (there are no useful operations to perform other
than, perhaps, "read the public key" or "try to load a module or
firmware").

 - Trying to containerize them makes very little sense until someone
proposes a resource that should be protected by such a key that might
live in a container.

 - There may be utility in allowing a new key to be added to the
keyring at runtime subject to a requirement that a PCR get extended.

The keyring subsystem provides a fancy syscall interface, a fancy
naming interface, a fancy protection interface, a fancy way to link
keys to threads and processes, etc, none of which seems particularly
useful here.  Using a "trusted" key for this purpose seems entirely
pointless (we can't sign no matter what the kernel does, so what
exactly would the TPM be protecting?).  The keyring subsystem is more
about restricting *usage* of keys, not *addition* of keys.  So it's
nice to use the keyring subsystem to add a key that grants access to a
resource (possibly some remote server) and restrict what can be done
with it, but the firmware/module usecase is entirely the other way
around: we're trying to restrict which keys can be added, and we're
allowing holders of the associated private keys to perform operations
that affect the local machine.

May I suggest a much, much simpler approach: use a plain old struct
list_head for each list of keys and use the crypto API directly for
verification?  Even better, use a list of registered verifier
callbacks where any callback in the list can say "ok, I recognize this
proposed firmware, module, etc".  Think LoadPin but without the LSM
baggage.  If someone really wants to use keyrings, then that facility
could use an optional module that registers a callback that does
exactly that.

--Andy
-- 
Andy Lutomirski
AMA Capital Management, LLC

Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi

[Mimi Zohar]

On Mi, 2016-07-27 at 13:09 -0700, Andy Lutomirski wrote:
> On Wed, Jul 27, 2016 at 12:37 PM, Mimi Zohar <zohar@linux.vnet.ibm.com> wrote:
> > On Mi, 2016-07-27 at 12:36 -0400, James Bottomley wrote:
> >> On Wed, 2016-07-27 at 12:28 -0400, James Bottomley wrote:
> >> > On Wed, 2016-07-27 at 17:14 +0100, David Howells wrote:
> >> > > James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
> >> > >

> I would like someone to explain why using the keyring mechanism for
> this in the first place is a good idea.
> 
> As far as I can tell, the design goals of "keys trusted by the kernel
> for modules, firmware, etc" are:
> 
>  - Keys are added at build time or, according to potentially
> system-specific rules, at boot time.

Currently, only the builtin keys are loaded onto the .builtin_trusted
keys. The keyring is locked so that no other keys can be added.  Trust
in these keys is based on the secure boot signature chain of trust
verification of the kernel image.

>  - Keys should specify what they're trusted *for*.  Some keys should
> be trusted to load modules.  Some keys should be trusted to load
> specific firmware files.

No argument there.  Keys can be added to the secondary keyring that are
signed by any key on either the builtin or secondary keyrings.  We would
need to limit this to only keys that are trusted *for* are permitted to
add such *for* keys to the keyring. 

>  - The kernel only knows the public part of these keys, so there's no
> particular need to restrict who can see them, who can perform
> operations with them (there are no useful operations to perform other
> than, perhaps, "read the public key" or "try to load a module or
> firmware").

Agreed

>  - Trying to containerize them makes very little sense until someone
> proposes a resource that should be protected by such a key that might
> live in a container.

Mat Martineau posted patches that extend the concept of a trusted
keyring to userspace.  It would allow a trusted keyring (new root of
trust or based on the builtin/secondary keyrings) to be attached to a
container/namespace.

>  - There may be utility in allowing a new key to be added to the
> keyring at runtime subject to a requirement that a PCR get extended.

The builtin keyring is locked, but they could be added to the secondary
keyring.

> The keyring subsystem provides a fancy syscall interface, a fancy
> naming interface, a fancy protection interface, a fancy way to link
> keys to threads and processes, etc, none of which seems particularly
> useful here.  Using a "trusted" key for this purpose seems entirely
> pointless (we can't sign no matter what the kernel does, so what
> exactly would the TPM be protecting?). 

The terms "trust"/"trusted" are being overloaded.  There is a "trusted"
key type, which are TPM based.  Then there are "trusted" keyrings, which
require any keys being added to the keyring to be signed by a key on the
builtin/secondary keyrings.

I'm referring to the latter case of extending the secure boot of
certificate chain of trust to a set of keys, in particular the builtin
keys.  These keys can then become the root of trust for any other keys
on other keyrings.

>  The keyring subsystem is more
> about restricting *usage* of keys, not *addition* of keys.  So it's
> nice to use the keyring subsystem to add a key that grants access to a
> resource (possibly some remote server) and restrict what can be done
> with it, but the firmware/module usecase is entirely the other way
> around: we're trying to restrict which keys can be added, and we're
> allowing holders of the associated private keys to perform operations
> that affect the local machine.

Yes, from an IMA perspective, only allow files signed by a certain set
of keys to be executed.   In a container, permit files signed by a
different/additional set of keys to execute.

> May I suggest a much, much simpler approach: use a plain old struct
> list_head for each list of keys and use the crypto API directly for
> verification?  Even better, use a list of registered verifier
> callbacks where any callback in the list can say "ok, I recognize this
> proposed firmware, module, etc".  Think LoadPin but without the LSM
> baggage.  If someone really wants to use keyrings, then that facility
> could use an optional module that registers a callback that does
> exactly that.

Last year at the Linux Security Summit, Petko Manolov and Mark Baush
(Juniper) presented a very different use case scenario -
http://kernsec.org/wiki/index.php/Linux_Security_Summit_2015/Abstracts/Manolov

Mimi

Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi

[Andy Lutomirski]

On Wed, Jul 27, 2016 at 3:54 PM, Mimi Zohar <zohar@linux.vnet.ibm.com> wrote:
> On Mi, 2016-07-27 at 13:09 -0700, Andy Lutomirski wrote:
>> On Wed, Jul 27, 2016 at 12:37 PM, Mimi Zohar <zohar@linux.vnet.ibm.com> wrote:
>> > On Mi, 2016-07-27 at 12:36 -0400, James Bottomley wrote:
>> >> On Wed, 2016-07-27 at 12:28 -0400, James Bottomley wrote:
>> >> > On Wed, 2016-07-27 at 17:14 +0100, David Howells wrote:
>> >> > > James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
>> >> > >
>
>> I would like someone to explain why using the keyring mechanism for
>> this in the first place is a good idea.
>>
>> As far as I can tell, the design goals of "keys trusted by the kernel
>> for modules, firmware, etc" are:
>>
>>  - Keys are added at build time or, according to potentially
>> system-specific rules, at boot time.
>
> Currently, only the builtin keys are loaded onto the .builtin_trusted
> keys. The keyring is locked so that no other keys can be added.  Trust
> in these keys is based on the secure boot signature chain of trust
> verification of the kernel image.
>
>>  - Keys should specify what they're trusted *for*.  Some keys should
>> be trusted to load modules.  Some keys should be trusted to load
>> specific firmware files.
>
> No argument there.  Keys can be added to the secondary keyring that are
> signed by any key on either the builtin or secondary keyrings.  We would
> need to limit this to only keys that are trusted *for* are permitted to
> add such *for* keys to the keyring.
>
>>  - The kernel only knows the public part of these keys, so there's no
>> particular need to restrict who can see them, who can perform
>> operations with them (there are no useful operations to perform other
>> than, perhaps, "read the public key" or "try to load a module or
>> firmware").
>
> Agreed
>
>>  - Trying to containerize them makes very little sense until someone
>> proposes a resource that should be protected by such a key that might
>> live in a container.
>
> Mat Martineau posted patches that extend the concept of a trusted
> keyring to userspace.  It would allow a trusted keyring (new root of
> trust or based on the builtin/secondary keyrings) to be attached to a
> container/namespace.

Can you clarify what this accomplishes?  If I make a namespace (by
calling clone or unshare) and attach a "trusted" keyring to it, what
effect do the keys in that keyring have?  I'd be quite surprised if
there's a valid use for trusting them for modules or firmware given
that namespaces have no business loading modules or firmware at all.

>
>>  - There may be utility in allowing a new key to be added to the
>> keyring at runtime subject to a requirement that a PCR get extended.
>
> The builtin keyring is locked, but they could be added to the secondary
> keyring.

Again, I think that wrapping this up in the "keyring" term is
problematic.  I'm saying that I can see a use case for allowing a
brand new key (not rooted anywhere in particular) to be added to the
list of trusted signing keys for modules so long as a PCR is extended
with that key.  That would let me seal things to a non-tampered-kernel
configuration by sealing them against an unextended PCR such that a
user who loaded a module not signed by the initial trusted key would
not be able to unseal the secrets.

>
>> The keyring subsystem provides a fancy syscall interface, a fancy
>> naming interface, a fancy protection interface, a fancy way to link
>> keys to threads and processes, etc, none of which seems particularly
>> useful here.  Using a "trusted" key for this purpose seems entirely
>> pointless (we can't sign no matter what the kernel does, so what
>> exactly would the TPM be protecting?).
>
> The terms "trust"/"trusted" are being overloaded.  There is a "trusted"
> key type, which are TPM based.  Then there are "trusted" keyrings, which
> require any keys being added to the keyring to be signed by a key on the
> builtin/secondary keyrings.

I really, really wish the latter usage would just go away.  Saying "I
trust this key" is just asking for trouble if you don't specify *what*
you trust it for.

>
> I'm referring to the latter case of extending the secure boot of
> certificate chain of trust to a set of keys, in particular the builtin
> keys.  These keys can then become the root of trust for any other keys
> on other keyrings.

Why?  This is an honest question -- I genuinely do not see why this is
a sensible thing to do.  If I have a platform that is configured to
allow modules signed by the Microsoft UEFI key to be loaded, why would
this imply that I also want to trust files with IMA signatures rooted
by the Microsoft UEFI key?  In fact, doing that seems likely to open
me up to remote attack depending on use case.

>
>>  The keyring subsystem is more
>> about restricting *usage* of keys, not *addition* of keys.  So it's
>> nice to use the keyring subsystem to add a key that grants access to a
>> resource (possibly some remote server) and restrict what can be done
>> with it, but the firmware/module usecase is entirely the other way
>> around: we're trying to restrict which keys can be added, and we're
>> allowing holders of the associated private keys to perform operations
>> that affect the local machine.
>
> Yes, from an IMA perspective, only allow files signed by a certain set
> of keys to be executed.   In a container, permit files signed by a
> different/additional set of keys to execute.

Now we're getting to the actual meat of this!  I can see legitimate
policy questions here.  For example, if I spawn a container, is it
okay for that container to execute a file that would not be permitted
to be executed outside that container?  (Both answers seem reasonable
depending on the administrator's goal.)

But I still tend to think that, even for IMA, we should be talking
about containerizing policy, not necessarily keyrings.  The cases
where the keyring interaction is interesting are (I think) cases where
you can also *write* to the IMA protected filesystem, in which case
you need the ability to sign in addition to verifying.

>
>> May I suggest a much, much simpler approach: use a plain old struct
>> list_head for each list of keys and use the crypto API directly for
>> verification?  Even better, use a list of registered verifier
>> callbacks where any callback in the list can say "ok, I recognize this
>> proposed firmware, module, etc".  Think LoadPin but without the LSM
>> baggage.  If someone really wants to use keyrings, then that facility
>> could use an optional module that registers a callback that does
>> exactly that.
>
> Last year at the Linux Security Summit, Petko Manolov and Mark Baush
> (Juniper) presented a very different use case scenario -
> http://kernsec.org/wiki/index.php/Linux_Security_Summit_2015/Abstracts/Manolov
>

I *still* see no reason that module policy and IMA policy should share
their implementations or interfaces.

Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi

[Mimi Zohar]

On Mi, 2016-07-27 at 16:15 -0700, Andy Lutomirski wrote:
> On Wed, Jul 27, 2016 at 3:54 PM, Mimi Zohar <zohar@linux.vnet.ibm.com> wrote:

> Again, I think that wrapping this up in the "keyring" term is
> problematic.  I'm saying that I can see a use case for allowing a
> brand new key (not rooted anywhere in particular) to be added to the
> list of trusted signing keys for modules so long as a PCR is extended
> with that key.  That would let me seal things to a non-tampered-kernel
> configuration by sealing them against an unextended PCR such that a
> user who loaded a module not signed by the initial trusted key would
> not be able to unseal the secrets.

Nice!  Ok, you create a key that is sealed to a set of PCRs and then
extend a PCR with a hash of the key.  Normally extending the PCR is to
prevent the key from being unsealed again.  In this case, I assume
you're preventing other keys from being created based on the initial
PCRs.  So you now have a key that matches an initial set of PCRs.  That
key can then be used to sign the kernel modules.  On reboot, the key is
unsealed iff the PCRs match.

If you're creating a TPM based key on the local host, that would require
your signing kernel modules locally.   With keyrings, the key for kernel
modules is already baked into the kernel and is loaded onto the builtin
keyring.  For code that the key isn't baked into the kernel, instead of
signing the code directly, the third party keys, which were used to sign
the code, would be signed by a key on the builtin keyring.

Mimi

Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi

[Andy Lutomirski]

[-- Attachment #1: Type: text/plain, Size: 1582 bytes --]

On Jul 27, 2016 8:17 PM, "Mimi Zohar" <zohar@linux.vnet.ibm.com> wrote:
>
> On Mi, 2016-07-27 at 16:15 -0700, Andy Lutomirski wrote:
> > On Wed, Jul 27, 2016 at 3:54 PM, Mimi Zohar <zohar@linux.vnet.ibm.com>
wrote:
>
> > Again, I think that wrapping this up in the "keyring" term is
> > problematic.  I'm saying that I can see a use case for allowing a
> > brand new key (not rooted anywhere in particular) to be added to the
> > list of trusted signing keys for modules so long as a PCR is extended
> > with that key.  That would let me seal things to a non-tampered-kernel
> > configuration by sealing them against an unextended PCR such that a
> > user who loaded a module not signed by the initial trusted key would
> > not be able to unseal the secrets.
>
> Nice!  Ok, you create a key that is sealed to a set of PCRs and then
> extend a PCR with a hash of the key.  Normally extending the PCR is to
> prevent the key from being unsealed again.  In this case, I assume
> you're preventing other keys from being created based on the initial
> PCRs.  So you now have a key that matches an initial set of PCRs.  That
> key can then be used to sign the kernel modules.  On reboot, the key is
> unsealed iff the PCRs match.

Not actually what I meant, but sure.  What I actually meant was that maybe
I have a secret (totally unrelated to kernel modules) that, by policy, I
should only be able to access on an un-tampered-with kernel.

With my little trick, I can still build and run random kernel modules.  If
I do so, though, I lose access to those protected secrets until reboot.

[-- Attachment #2: Type: text/html, Size: 1982 bytes --]

Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi

[Jason Cooper]

Hi Andy,

On Wed, Jul 27, 2016 at 01:09:37PM -0700, Andy Lutomirski wrote:
...
> I would like someone to explain why using the keyring mechanism for
> this in the first place is a good idea.
> 
> As far as I can tell, the design goals of "keys trusted by the kernel
> for modules, firmware, etc" are:
> 
>  - Keys are added at build time or, according to potentially
> system-specific rules, at boot time.
> 
>  - Keys should specify what they're trusted *for*.

Well, I'd argue that keys should specify what they are *intended* for by
the keyholder.  A useful security system could further restrict the key
as needed.

e.g. the Microsoft key may say it's intended for "Verifying binaries
issued by Microsoft".  A Linux user would want to restrict that to
verifying updated boot shims for UEFI.

If nothing else, we need to grok the lessons learned from the CA
system.

> Some keys should be trusted to load modules.  Some keys should be
> trusted to load specific firmware files.

"Some keys should be restricted to verifying modules.  Some keys should
be restricted to verifying specific firmware files." [0]

We'll know the system is designed correctly if we don't mind the
Microsoft key being in the keyring.

There's definitely a larger conversation to be had here.  The Kernel is
a *part* of the system, and should be a *part* of the security of the
system.  Attempting to make it the whole enchilada risks making the same
design errors as TrustZone.  "Just put all your eggs in this *other*
basket.  No one can see in it, but it has access to everything on the
system.  Oh, you have proprietary, complicated, un-reviewed DRM code
that parses unsanitized input?  Sure, put it in there with the key
manager.  No problem, it's magic."  Moving cheese. [1]

thx,

Jason.

[0] A wise man once told me to avoid the word 'trust' in conversations
about security.  It's a vague term whose meaning varies from person to
person and from situation to situation.

[1] https://bits-please.blogspot.de/2016/06/extracting-qualcomms-keymaster-keys.html

Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi

[Mimi Zohar]

On Do, 2016-07-28 at 16:57 +0000, Jason Cooper wrote:
> Hi Andy,
> 
> On Wed, Jul 27, 2016 at 01:09:37PM -0700, Andy Lutomirski wrote:
> ...
> > I would like someone to explain why using the keyring mechanism for
> > this in the first place is a good idea.
> > 
> > As far as I can tell, the design goals of "keys trusted by the kernel
> > for modules, firmware, etc" are:
> > 
> >  - Keys are added at build time or, according to potentially
> > system-specific rules, at boot time.
> > 
> >  - Keys should specify what they're trusted *for*.
> 
> Well, I'd argue that keys should specify what they are *intended* for by
> the keyholder.  A useful security system could further restrict the key
> as needed.

We've already started.  Currently the kernel_read_file() and family of
functions provide the LSM hooks needed for verifying file signatures of
files read by the kernel.  The kernel_read_file_id enumeration is used
to differentiate between callers.  Based on this enumeration, the
*intended* for could be defined.  It would make sense to extend the IMA
policy language to support *intended* for.

Mimi

> e.g. the Microsoft key may say it's intended for "Verifying binaries
> issued by Microsoft".  A Linux user would want to restrict that to
> verifying updated boot shims for UEFI.
> 
> If nothing else, we need to grok the lessons learned from the CA
> system.
> 
> > Some keys should be trusted to load modules.  Some keys should be
> > trusted to load specific firmware files.
> 
> "Some keys should be restricted to verifying modules.  Some keys should
> be restricted to verifying specific firmware files." [0]
> 
> We'll know the system is designed correctly if we don't mind the
> Microsoft key being in the keyring.
> 
> There's definitely a larger conversation to be had here.  The Kernel is
> a *part* of the system, and should be a *part* of the security of the
> system.  Attempting to make it the whole enchilada risks making the same
> design errors as TrustZone.  "Just put all your eggs in this *other*
> basket.  No one can see in it, but it has access to everything on the
> system.  Oh, you have proprietary, complicated, un-reviewed DRM code
> that parses unsanitized input?  Sure, put it in there with the key
> manager.  No problem, it's magic."  Moving cheese. [1]
> 
> thx,
> 
> Jason.
> 
> [0] A wise man once told me to avoid the word 'trust' in conversations
> about security.  It's a vague term whose meaning varies from person to
> person and from situation to situation.
> 
> [1] https://bits-please.blogspot.de/2016/06/extracting-qualcomms-keymaster-keys.html
> 

Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi

[Andy Lutomirski]

On Fri, Jul 29, 2016 at 3:10 PM, Mimi Zohar <zohar@linux.vnet.ibm.com> wrote:
> On Do, 2016-07-28 at 16:57 +0000, Jason Cooper wrote:
>> Hi Andy,
>>
>> On Wed, Jul 27, 2016 at 01:09:37PM -0700, Andy Lutomirski wrote:
>> ...
>> > I would like someone to explain why using the keyring mechanism for
>> > this in the first place is a good idea.
>> >
>> > As far as I can tell, the design goals of "keys trusted by the kernel
>> > for modules, firmware, etc" are:
>> >
>> >  - Keys are added at build time or, according to potentially
>> > system-specific rules, at boot time.
>> >
>> >  - Keys should specify what they're trusted *for*.
>>
>> Well, I'd argue that keys should specify what they are *intended* for by
>> the keyholder.  A useful security system could further restrict the key
>> as needed.
>
> We've already started.  Currently the kernel_read_file() and family of
> functions provide the LSM hooks needed for verifying file signatures of
> files read by the kernel.  The kernel_read_file_id enumeration is used
> to differentiate between callers.  Based on this enumeration, the
> *intended* for could be defined.  It would make sense to extend the IMA
> policy language to support *intended* for.
>

Having kernel_read_file know the purpose is a big step in the right
direction, although, as I think I and others have pointed out, just an
enum is insufficient -- for firmware, at least, the *name* is
relevant.

But this is almost orthogonal to what I'm talking about.  I'm saying
that, before seriously considering any extensions to using keyrings to
decide which files are okay for kernel_read_file() and similar, we
should first consider whether using keyrings *at all* for this is a
reasonable long-term approach.  Elsewhere in this thread, Jason Cooper
mentioned keyholders.  For this type of verification key, the holder
isn't even on the same machine as the kernel on which
kernel_read_file() is called.

Sure, one might want to configure a system so IMA is used for
kernel_read_file(), and one might want to configure IMA to use
keyrings, but that's far from being the only sensible configuration.

--Andy

Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi

[Luis R. Rodriguez]

On Fri, Jul 29, 2016 at 03:25:09PM -0700, Andy Lutomirski wrote:
> On Fri, Jul 29, 2016 at 3:10 PM, Mimi Zohar <zohar@linux.vnet.ibm.com> wrote:
> > On Do, 2016-07-28 at 16:57 +0000, Jason Cooper wrote:
> >> Hi Andy,
> >>
> >> On Wed, Jul 27, 2016 at 01:09:37PM -0700, Andy Lutomirski wrote:
> >> ...
> >> > I would like someone to explain why using the keyring mechanism for
> >> > this in the first place is a good idea.
> >> >
> >> > As far as I can tell, the design goals of "keys trusted by the kernel
> >> > for modules, firmware, etc" are:
> >> >
> >> >  - Keys are added at build time or, according to potentially
> >> > system-specific rules, at boot time.
> >> >
> >> >  - Keys should specify what they're trusted *for*.
> >>
> >> Well, I'd argue that keys should specify what they are *intended* for by
> >> the keyholder.  A useful security system could further restrict the key
> >> as needed.
> >
> > We've already started.  Currently the kernel_read_file() and family of
> > functions provide the LSM hooks needed for verifying file signatures of
> > files read by the kernel.  The kernel_read_file_id enumeration is used
> > to differentiate between callers.  Based on this enumeration, the
> > *intended* for could be defined.  It would make sense to extend the IMA
> > policy language to support *intended* for.
> >
> 
> Having kernel_read_file know the purpose is a big step in the right
> direction, although, as I think I and others have pointed out, just an
> enum is insufficient -- for firmware, at least, the *name* is
> relevant.

The name is passed for firmware, the wrapper kernel_read_file_from_path()
is used. So if we wanted an LSM extension on name I think we can do that
on kernel_read_file_from_path() ?

> But this is almost orthogonal to what I'm talking about.  I'm saying
> that, before seriously considering any extensions to using keyrings to
> decide which files are okay for kernel_read_file() and similar, we
> should first consider whether using keyrings *at all* for this is a
> reasonable long-term approach.

It sounds like an LSM decision ?

Of course, part of the issue with signing / keyring stuff here is
module signing wasn't designed as an LSM, I've discussed with David
the possibility of LSM'ifying kernel signing infrastructure, with
a lot of works it seems possible. With LSM stacking this then should
group up together in a sensible way. Then for instance eventually
module signing and firmware singing could be stackable LSM decisions,
and not a kconfig final decision -- as they are today. To me though
having module signing or firmware signing be LSM'ifable is not a hard
requirement given its just ways to do things, so its not a requirement,
architecturally its just better to have long term. So when I say this
sounds like an LSM decision I'm projecting on to how this question
of keyrings then becomes a stackable LSM question.

> Elsewhere in this thread, Jason Cooper
> mentioned keyholders.  For this type of verification key, the holder
> isn't even on the same machine as the kernel on which
> kernel_read_file() is called.

When you run a distro kernel your kernel key holder isn't on the
same machine either. Then for that shiny mobile OS that runs Linux,
they use LoadPin LSM, so they have opted out of the keyholder/keyring
thing but punted it in another way.

In the stackable LSM context, what is not possible then?

> Sure, one might want to configure a system so IMA is used for
> kernel_read_file(), and one might want to configure IMA to use
> keyrings, but that's far from being the only sensible configuration.

If we LSM'ify it all, then I think anything should be possible so long
as we pass on to the LSM enough context. Since we already pass context
of how something is read that should help. Path seems like the next
target ? Anything else ?

  Luis

Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi

[Mimi Zohar]

On Sa, 2016-07-30 at 18:36 +0200, Luis R. Rodriguez wrote:
> On Fri, Jul 29, 2016 at 03:25:09PM -0700, Andy Lutomirski wrote:
> > On Fri, Jul 29, 2016 at 3:10 PM, Mimi Zohar <zohar@linux.vnet.ibm.com> wrote:
> > > On Do, 2016-07-28 at 16:57 +0000, Jason Cooper wrote:
> > >> Hi Andy,
> > >>
> > >> On Wed, Jul 27, 2016 at 01:09:37PM -0700, Andy Lutomirski wrote:
> > >> ...
> > >> > I would like someone to explain why using the keyring mechanism for
> > >> > this in the first place is a good idea.
> > >> >
> > >> > As far as I can tell, the design goals of "keys trusted by the kernel
> > >> > for modules, firmware, etc" are:
> > >> >
> > >> >  - Keys are added at build time or, according to potentially
> > >> > system-specific rules, at boot time.
> > >> >
> > >> >  - Keys should specify what they're trusted *for*.
> > >>
> > >> Well, I'd argue that keys should specify what they are *intended* for by
> > >> the keyholder.  A useful security system could further restrict the key
> > >> as needed.
> > >
> > > We've already started.  Currently the kernel_read_file() and family of
> > > functions provide the LSM hooks needed for verifying file signatures of
> > > files read by the kernel.  The kernel_read_file_id enumeration is used
> > > to differentiate between callers.  Based on this enumeration, the
> > > *intended* for could be defined.  It would make sense to extend the IMA
> > > policy language to support *intended* for.
> > >
> > 
> > Having kernel_read_file know the purpose is a big step in the right
> > direction, although, as I think I and others have pointed out, just an
> > enum is insufficient -- for firmware, at least, the *name* is
> > relevant.

> The name is passed for firmware, the wrapper kernel_read_file_from_path()
> is used. So if we wanted an LSM extension on name I think we can do that
> on kernel_read_file_from_path() ?

It shouldn't make a difference whether kernel_read_file() is called
directly, or the kernel_read_file_by_path/fd() are called.  The pathname
is accessible from the "file" argument.

> > But this is almost orthogonal to what I'm talking about.  I'm saying
> > that, before seriously considering any extensions to using keyrings to
> > decide which files are okay for kernel_read_file() and similar, we
> > should first consider whether using keyrings *at all* for this is a
> > reasonable long-term approach.
> 
> It sounds like an LSM decision ?
> 
> Of course, part of the issue with signing / keyring stuff here is
> module signing wasn't designed as an LSM, I've discussed with David
> the possibility of LSM'ifying kernel signing infrastructure, with
> a lot of works it seems possible. With LSM stacking this then should
> group up together in a sensible way. Then for instance eventually
> module signing and firmware singing could be stackable LSM decisions,
> and not a kconfig final decision -- as they are today. To me though
> having module signing or firmware signing be LSM'ifable is not a hard
> requirement given its just ways to do things, so its not a requirement,
> architecturally its just better to have long term. So when I say this
> sounds like an LSM decision I'm projecting on to how this question
> of keyrings then becomes a stackable LSM question.
> 
> > Elsewhere in this thread, Jason Cooper
> > mentioned keyholders.  For this type of verification key, the holder
> > isn't even on the same machine as the kernel on which
> > kernel_read_file() is called.
> 
> When you run a distro kernel your kernel key holder isn't on the
> same machine either. Then for that shiny mobile OS that runs Linux,
> they use LoadPin LSM, so they have opted out of the keyholder/keyring
> thing but punted it in another way.
> 
> In the stackable LSM context, what is not possible then?
> 
> > Sure, one might want to configure a system so IMA is used for
> > kernel_read_file(), and one might want to configure IMA to use
> > keyrings, but that's far from being the only sensible configuration.
> 
> If we LSM'ify it all, then I think anything should be possible so long
> as we pass on to the LSM enough context. Since we already pass context
> of how something is read that should help. Path seems like the next
> target ? Anything else ?

One issue that repeatedly comes up, at least for IMA, is key management.
Will the keys be used solely for code provenance or to also provide
version control?

Mimi

Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi

[Andy Lutomirski]

[-- Attachment #1: Type: text/plain, Size: 2252 bytes --]

On Jul 30, 2016 8:08 PM, "Mimi Zohar" <zohar@linux.vnet.ibm.com> wrote:
>
> On Sa, 2016-07-30 at 18:36 +0200, Luis R. Rodriguez wrote:
> > On Fri, Jul 29, 2016 at 03:25:09PM -0700, Andy Lutomirski wrote:
> > > On Fri, Jul 29, 2016 at 3:10 PM, Mimi Zohar <zohar@linux.vnet.ibm.com>
wrote:
> > > > On Do, 2016-07-28 at 16:57 +0000, Jason Cooper wrote:
> > > >> Hi Andy,
> > > >>
> > > >> On Wed, Jul 27, 2016 at 01:09:37PM -0700, Andy Lutomirski wrote:
> > > >> ...
> > > >> > I would like someone to explain why using the keyring mechanism
for
> > > >> > this in the first place is a good idea.
> > > >> >
> > > >> > As far as I can tell, the design goals of "keys trusted by the
kernel
> > > >> > for modules, firmware, etc" are:
> > > >> >
> > > >> >  - Keys are added at build time or, according to potentially
> > > >> > system-specific rules, at boot time.
> > > >> >
> > > >> >  - Keys should specify what they're trusted *for*.
> > > >>
> > > >> Well, I'd argue that keys should specify what they are *intended*
for by
> > > >> the keyholder.  A useful security system could further restrict
the key
> > > >> as needed.
> > > >
> > > > We've already started.  Currently the kernel_read_file() and family
of
> > > > functions provide the LSM hooks needed for verifying file
signatures of
> > > > files read by the kernel.  The kernel_read_file_id enumeration is
used
> > > > to differentiate between callers.  Based on this enumeration, the
> > > > *intended* for could be defined.  It would make sense to extend the
IMA
> > > > policy language to support *intended* for.
> > > >
> > >
> > > Having kernel_read_file know the purpose is a big step in the right
> > > direction, although, as I think I and others have pointed out, just an
> > > enum is insufficient -- for firmware, at least, the *name* is
> > > relevant.
>
> > The name is passed for firmware, the wrapper
kernel_read_file_from_path()
> > is used. So if we wanted an LSM extension on name I think we can do that
> > on kernel_read_file_from_path() ?
>
> It shouldn't make a difference whether kernel_read_file() is called
> directly, or the kernel_read_file_by_path/fd() are called.  The pathname
> is accessible from the "file" argument.
>

What happens if a symlink is involved?

[-- Attachment #2: Type: text/html, Size: 3199 bytes --]

Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi

[Mimi Zohar]

On Sa, 2016-07-30 at 20:09 -0700, Andy Lutomirski wrote:
> On Jul 30, 2016 8:08 PM, "Mimi Zohar" <zohar@linux.vnet.ibm.com> wrote:
> >
> > On Sa, 2016-07-30 at 18:36 +0200, Luis R. Rodriguez wrote:
> > > On Fri, Jul 29, 2016 at 03:25:09PM -0700, Andy Lutomirski wrote:
> > > > On Fri, Jul 29, 2016 at 3:10 PM, Mimi Zohar <zohar@linux.vnet.ibm.com>
> wrote:
> > > > > On Do, 2016-07-28 at 16:57 +0000, Jason Cooper wrote:
> > > > >> Hi Andy,
> > > > >>
> > > > >> On Wed, Jul 27, 2016 at 01:09:37PM -0700, Andy Lutomirski wrote:
> > > > >> ...
> > > > >> > I would like someone to explain why using the keyring mechanism
> for
> > > > >> > this in the first place is a good idea.
> > > > >> >
> > > > >> > As far as I can tell, the design goals of "keys trusted by the
> kernel
> > > > >> > for modules, firmware, etc" are:
> > > > >> >
> > > > >> >  - Keys are added at build time or, according to potentially
> > > > >> > system-specific rules, at boot time.
> > > > >> >
> > > > >> >  - Keys should specify what they're trusted *for*.
> > > > >>
> > > > >> Well, I'd argue that keys should specify what they are *intended*
> for by
> > > > >> the keyholder.  A useful security system could further restrict
> the key
> > > > >> as needed.
> > > > >
> > > > > We've already started.  Currently the kernel_read_file() and family
> of
> > > > > functions provide the LSM hooks needed for verifying file
> signatures of
> > > > > files read by the kernel.  The kernel_read_file_id enumeration is
> used
> > > > > to differentiate between callers.  Based on this enumeration, the
> > > > > *intended* for could be defined.  It would make sense to extend the
> IMA
> > > > > policy language to support *intended* for.
> > > > >
> > > >
> > > > Having kernel_read_file know the purpose is a big step in the right
> > > > direction, although, as I think I and others have pointed out, just an
> > > > enum is insufficient -- for firmware, at least, the *name* is
> > > > relevant.
> >
> > > The name is passed for firmware, the wrapper
> kernel_read_file_from_path()
> > > is used. So if we wanted an LSM extension on name I think we can do that
> > > on kernel_read_file_from_path() ?
> >
> > It shouldn't make a difference whether kernel_read_file() is called
> > directly, or the kernel_read_file_by_path/fd() are called.  The pathname
> > is accessible from the "file" argument.
> >
> 
> What happens if a symlink is involved?

For callers of kernel_read_file_by_path(), like firmware, we could pass
the pathname, but for the other callers of kernel_read_file/_by_fd() we
could use d_absolute_path().

Mimi

Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi

[Andy Lutomirski]

On Sun, Jul 31, 2016 at 8:31 AM, Mimi Zohar <zohar@linux.vnet.ibm.com> wrote:
> On Sa, 2016-07-30 at 20:09 -0700, Andy Lutomirski wrote:
>> On Jul 30, 2016 8:08 PM, "Mimi Zohar" <zohar@linux.vnet.ibm.com> wrote:
>> >
>> > On Sa, 2016-07-30 at 18:36 +0200, Luis R. Rodriguez wrote:
>> > > On Fri, Jul 29, 2016 at 03:25:09PM -0700, Andy Lutomirski wrote:
>> > > > On Fri, Jul 29, 2016 at 3:10 PM, Mimi Zohar <zohar@linux.vnet.ibm.com>
>> wrote:
>> > > > > On Do, 2016-07-28 at 16:57 +0000, Jason Cooper wrote:
>> > > > >> Hi Andy,
>> > > > >>
>> > > > >> On Wed, Jul 27, 2016 at 01:09:37PM -0700, Andy Lutomirski wrote:
>> > > > >> ...
>> > > > >> > I would like someone to explain why using the keyring mechanism
>> for
>> > > > >> > this in the first place is a good idea.
>> > > > >> >
>> > > > >> > As far as I can tell, the design goals of "keys trusted by the
>> kernel
>> > > > >> > for modules, firmware, etc" are:
>> > > > >> >
>> > > > >> >  - Keys are added at build time or, according to potentially
>> > > > >> > system-specific rules, at boot time.
>> > > > >> >
>> > > > >> >  - Keys should specify what they're trusted *for*.
>> > > > >>
>> > > > >> Well, I'd argue that keys should specify what they are *intended*
>> for by
>> > > > >> the keyholder.  A useful security system could further restrict
>> the key
>> > > > >> as needed.
>> > > > >
>> > > > > We've already started.  Currently the kernel_read_file() and family
>> of
>> > > > > functions provide the LSM hooks needed for verifying file
>> signatures of
>> > > > > files read by the kernel.  The kernel_read_file_id enumeration is
>> used
>> > > > > to differentiate between callers.  Based on this enumeration, the
>> > > > > *intended* for could be defined.  It would make sense to extend the
>> IMA
>> > > > > policy language to support *intended* for.
>> > > > >
>> > > >
>> > > > Having kernel_read_file know the purpose is a big step in the right
>> > > > direction, although, as I think I and others have pointed out, just an
>> > > > enum is insufficient -- for firmware, at least, the *name* is
>> > > > relevant.
>> >
>> > > The name is passed for firmware, the wrapper
>> kernel_read_file_from_path()
>> > > is used. So if we wanted an LSM extension on name I think we can do that
>> > > on kernel_read_file_from_path() ?
>> >
>> > It shouldn't make a difference whether kernel_read_file() is called
>> > directly, or the kernel_read_file_by_path/fd() are called.  The pathname
>> > is accessible from the "file" argument.
>> >
>>l
>> What happens if a symlink is involved?
>
> For callers of kernel_read_file_by_path(), like firmware, we could pass
> the pathname, but for the other callers of kernel_read_file/_by_fd() we
> could use d_absolute_path().

That seems pointlessly fragile to me, and this issue has been known
for longer than the code in question has even existed.  How about:

struct kernel_trusted_file_description {
  enum kernel_read_file_id type;
  const char *specific_purpose;  /* may be NULL for KEXEC_IMAGE, etc. */
};

int kernel_read_file(struct file *, void **, loff_t *, const struct
trusted_file_description *);

rather than trying to guess.

Also, are there any plans to move module signature verification into
.kernel_post_read_file?

--Andy

Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi

[Mimi Zohar]

On So, 2016-07-31 at 09:19 -0700, Andy Lutomirski wrote:
> On Sun, Jul 31, 2016 at 8:31 AM, Mimi Zohar <zohar@linux.vnet.ibm.com> wrote:
> > On Sa, 2016-07-30 at 20:09 -0700, Andy Lutomirski wrote:
> >> On Jul 30, 2016 8:08 PM, "Mimi Zohar" <zohar@linux.vnet.ibm.com> wrote:
> >> >
> >> > On Sa, 2016-07-30 at 18:36 +0200, Luis R. Rodriguez wrote:
> >> > > On Fri, Jul 29, 2016 at 03:25:09PM -0700, Andy Lutomirski wrote:
> >> > > > On Fri, Jul 29, 2016 at 3:10 PM, Mimi Zohar <zohar@linux.vnet.ibm.com>
> >> wrote:
> >> > > > > On Do, 2016-07-28 at 16:57 +0000, Jason Cooper wrote:
> >> > > > >> Hi Andy,
> >> > > > >>
> >> > > > >> On Wed, Jul 27, 2016 at 01:09:37PM -0700, Andy Lutomirski wrote:
> >> > > > >> ...
> >> > > > >> > I would like someone to explain why using the keyring mechanism
> >> for
> >> > > > >> > this in the first place is a good idea.
> >> > > > >> >
> >> > > > >> > As far as I can tell, the design goals of "keys trusted by the
> >> kernel
> >> > > > >> > for modules, firmware, etc" are:
> >> > > > >> >
> >> > > > >> >  - Keys are added at build time or, according to potentially
> >> > > > >> > system-specific rules, at boot time.
> >> > > > >> >
> >> > > > >> >  - Keys should specify what they're trusted *for*.
> >> > > > >>
> >> > > > >> Well, I'd argue that keys should specify what they are *intended*
> >> for by
> >> > > > >> the keyholder.  A useful security system could further restrict
> >> the key
> >> > > > >> as needed.
> >> > > > >
> >> > > > > We've already started.  Currently the kernel_read_file() and family
> >> of
> >> > > > > functions provide the LSM hooks needed for verifying file
> >> signatures of
> >> > > > > files read by the kernel.  The kernel_read_file_id enumeration is
> >> used
> >> > > > > to differentiate between callers.  Based on this enumeration, the
> >> > > > > *intended* for could be defined.  It would make sense to extend the
> >> IMA
> >> > > > > policy language to support *intended* for.
> >> > > > >
> >> > > >
> >> > > > Having kernel_read_file know the purpose is a big step in the right
> >> > > > direction, although, as I think I and others have pointed out, just an
> >> > > > enum is insufficient -- for firmware, at least, the *name* is
> >> > > > relevant.
> >> >
> >> > > The name is passed for firmware, the wrapper
> >> kernel_read_file_from_path()
> >> > > is used. So if we wanted an LSM extension on name I think we can do that
> >> > > on kernel_read_file_from_path() ?
> >> >
> >> > It shouldn't make a difference whether kernel_read_file() is called
> >> > directly, or the kernel_read_file_by_path/fd() are called.  The pathname
> >> > is accessible from the "file" argument.
> >> >
> >>l
> >> What happens if a symlink is involved?
> >
> > For callers of kernel_read_file_by_path(), like firmware, we could pass
> > the pathname, but for the other callers of kernel_read_file/_by_fd() we
> > could use d_absolute_path().
> 
> That seems pointlessly fragile to me, and this issue has been known
> for longer than the code in question has even existed.  How about:
> 
> struct kernel_trusted_file_description {
>   enum kernel_read_file_id type;
>   const char *specific_purpose;  /* may be NULL for KEXEC_IMAGE, etc. */
> };
> 
> int kernel_read_file(struct file *, void **, loff_t *, const struct
> trusted_file_description *);
> 
> rather than trying to guess.
> 
> Also, are there any plans to move module signature verification into
> .kernel_post_read_file?

The whole point of defining the kernel_read_file() family of functions
was to close a class of measurement/appraisal gaps.   To answer your
question, yes IMA measures and/or appraises files on the security post
kernel read hook, based on policy.

Andy, other than IMA-appraisal being xattr based,  I'm not sure why
you're so against it.   if you're going to be at LinuxCon/LSS, perhaps
we could speak in person there.

Mimi

Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi

[Andy Lutomirski]

[-- Attachment #1: Type: text/plain, Size: 4525 bytes --]

On Jul 31, 2016 10:29 AM, "Mimi Zohar" <zohar@linux.vnet.ibm.com> wrote:
>
> On So, 2016-07-31 at 09:19 -0700, Andy Lutomirski wrote:
> > On Sun, Jul 31, 2016 at 8:31 AM, Mimi Zohar <zohar@linux.vnet.ibm.com>
wrote:
> > > On Sa, 2016-07-30 at 20:09 -0700, Andy Lutomirski wrote:
> > >> On Jul 30, 2016 8:08 PM, "Mimi Zohar" <zohar@linux.vnet.ibm.com>
wrote:
> > >> >
> > >> > On Sa, 2016-07-30 at 18:36 +0200, Luis R. Rodriguez wrote:
> > >> > > On Fri, Jul 29, 2016 at 03:25:09PM -0700, Andy Lutomirski wrote:
> > >> > > > On Fri, Jul 29, 2016 at 3:10 PM, Mimi Zohar <
zohar@linux.vnet.ibm.com>
> > >> wrote:
> > >> > > > > On Do, 2016-07-28 at 16:57 +0000, Jason Cooper wrote:
> > >> > > > >> Hi Andy,
> > >> > > > >>
> > >> > > > >> On Wed, Jul 27, 2016 at 01:09:37PM -0700, Andy Lutomirski
wrote:
> > >> > > > >> ...
> > >> > > > >> > I would like someone to explain why using the keyring
mechanism
> > >> for
> > >> > > > >> > this in the first place is a good idea.
> > >> > > > >> >
> > >> > > > >> > As far as I can tell, the design goals of "keys trusted
by the
> > >> kernel
> > >> > > > >> > for modules, firmware, etc" are:
> > >> > > > >> >
> > >> > > > >> >  - Keys are added at build time or, according to
potentially
> > >> > > > >> > system-specific rules, at boot time.
> > >> > > > >> >
> > >> > > > >> >  - Keys should specify what they're trusted *for*.
> > >> > > > >>
> > >> > > > >> Well, I'd argue that keys should specify what they are
*intended*
> > >> for by
> > >> > > > >> the keyholder.  A useful security system could further
restrict
> > >> the key
> > >> > > > >> as needed.
> > >> > > > >
> > >> > > > > We've already started.  Currently the kernel_read_file() and
family
> > >> of
> > >> > > > > functions provide the LSM hooks needed for verifying file
> > >> signatures of
> > >> > > > > files read by the kernel.  The kernel_read_file_id
enumeration is
> > >> used
> > >> > > > > to differentiate between callers.  Based on this
enumeration, the
> > >> > > > > *intended* for could be defined.  It would make sense to
extend the
> > >> IMA
> > >> > > > > policy language to support *intended* for.
> > >> > > > >
> > >> > > >
> > >> > > > Having kernel_read_file know the purpose is a big step in the
right
> > >> > > > direction, although, as I think I and others have pointed out,
just an
> > >> > > > enum is insufficient -- for firmware, at least, the *name* is
> > >> > > > relevant.
> > >> >
> > >> > > The name is passed for firmware, the wrapper
> > >> kernel_read_file_from_path()
> > >> > > is used. So if we wanted an LSM extension on name I think we can
do that
> > >> > > on kernel_read_file_from_path() ?
> > >> >
> > >> > It shouldn't make a difference whether kernel_read_file() is called
> > >> > directly, or the kernel_read_file_by_path/fd() are called.  The
pathname
> > >> > is accessible from the "file" argument.
> > >> >
> > >>l
> > >> What happens if a symlink is involved?
> > >
> > > For callers of kernel_read_file_by_path(), like firmware, we could
pass
> > > the pathname, but for the other callers of kernel_read_file/_by_fd()
we
> > > could use d_absolute_path().
> >
> > That seems pointlessly fragile to me, and this issue has been known
> > for longer than the code in question has even existed.  How about:
> >
> > struct kernel_trusted_file_description {
> >   enum kernel_read_file_id type;
> >   const char *specific_purpose;  /* may be NULL for KEXEC_IMAGE, etc. */
> > };
> >
> > int kernel_read_file(struct file *, void **, loff_t *, const struct
> > trusted_file_description *);
> >
> > rather than trying to guess.
> >
> > Also, are there any plans to move module signature verification into
> > .kernel_post_read_file?
>
> The whole point of defining the kernel_read_file() family of functions
> was to close a class of measurement/appraisal gaps.

And to enable firmware verification?

>   To answer your
> question, yes IMA measures and/or appraises files on the security post
> kernel read hook, based on policy.

I wasn't asking anything about IMA.

>
> Andy, other than IMA-appraisal being xattr based,  I'm not sure why
> you're so against it.   if you're going to be at LinuxCon/LSS, perhaps
> we could speak in person there.

I have nothing against IMA.  I have plenty of objection to the core hooks
being simultaneously messy and not supplying enough information to provide
the security properties they should provide.

If IMA doesn't want or need to verify the purpose of the loaded file, fine.

I'll be at KS but not LSS.

--Andy

[-- Attachment #2: Type: text/html, Size: 6831 bytes --]

Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi

[Mimi Zohar]

On So, 2016-07-31 at 11:20 -0700, Andy Lutomirski wrote:
> On Jul 31, 2016 10:29 AM, "Mimi Zohar" <zohar@linux.vnet.ibm.com> wrote:

> > > Also, are there any plans to move module signature verification into
> > > .kernel_post_read_file?
> >
> > The whole point of defining the kernel_read_file() family of functions
> > was to close a class of measurement/appraisal gaps.
> 
> And to enable firmware verification?

Yes, including firmware signature verification.

> >   To answer your
> > question, yes IMA measures and/or appraises files on the security post
> > kernel read hook, based on policy.
> 
> I wasn't asking anything about IMA.

>From my understanding of your question, you're asking if there is an LSM
that uses this hook for verifying firmware signatures.  IMA uses the LSM
hooks and defines a few additional hooks to enforce file integrity.
For all practical purposes it is an LSM+.

> > Andy, other than IMA-appraisal being xattr based,  I'm not sure why
> > you're so against it.   if you're going to be at LinuxCon/LSS, perhaps
> > we could speak in person there.
> 
> I have nothing against IMA.  I have plenty of objection to the core hooks
> being simultaneously messy and not supplying enough information to provide
> the security properties they should provide.

The discussions took place on the kexec, firmware, kernel modules and
LSM mailing lists late last year and earlier this year.  You could have
commented on the patches and raised your concerns then, but it isn't too
late at this point.  These are internal functions, not an external API
that can not be modified.

Though, before making any changes we should address Luis' question,
"Path seems like the next target?  Anything else ?"

Mimi

Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi

[Luis R. Rodriguez]

On Sun, Jul 31, 2016 at 11:20:08AM -0700, Andy Lutomirski wrote:
> If IMA doesn't want or need to verify the purpose of the loaded file, fine.

So other than origin you are indicating a proper LSM that would want to vet firmware
should want purpose ? Is that right? If so I'd like to understand this suggestion
a bit better given we already have. So we have:

#define __kernel_read_file_id(id) \                                             
        id(UNKNOWN, unknown)            \                                       
        id(FIRMWARE, firmware)          \                                       
        id(FIRMWARE_PREALLOC_BUFFER, firmware)  \                               
        id(MODULE, kernel-module)               \                               
        id(KEXEC_IMAGE, kexec-image)            \                               
        id(KEXEC_INITRAMFS, kexec-initramfs)    \                               
        id(POLICY, security-policy)             \                               
        id(MAX_ID, )   

                                                                                
#define __fid_enumify(ENUM, dummy) READING_ ## ENUM,                            
#define __fid_stringify(dummy, str) #str,                                       
                                                                                
enum kernel_read_file_id {                                                      
        __kernel_read_file_id(__fid_enumify)                                    
};

extern int kernel_read_file_from_path(char *, void **, loff_t *, loff_t,        
                                      enum kernel_read_file_id);

Are you saying FIRMWARE id is not sufficient ? What would be an example
purpose be here for FIRMWARE ?

  Luis

Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi

[Andy Lutomirski]

On Mon, Aug 1, 2016 at 10:29 AM, Luis R. Rodriguez <mcgrof@suse.com> wrote:
> On Sun, Jul 31, 2016 at 11:20:08AM -0700, Andy Lutomirski wrote:
>> If IMA doesn't want or need to verify the purpose of the loaded file, fine.
>
> So other than origin you are indicating a proper LSM that would want to vet firmware
> should want purpose ? Is that right?

An security policy that wants to provide strong protection should
verify that whatever file is being loaded is being used for its
authorized purpose.  The wireless regulatory subsystem should only
load data signed by the wifi regulatory key, the iwlwifi driver should
only accept firmware signed by the system *for the purpose of being
used as iwlwifi firmware* (or perhaps signed by Intel), the nouveau
driver should accept files signed for the purpose of being used as
nvidia firmware and should reject things that are signed by Intel,
etc.

> If so I'd like to understand this suggestion
> a bit better given we already have. So we have:
>
> #define __kernel_read_file_id(id) \
>         id(UNKNOWN, unknown)            \
>         id(FIRMWARE, firmware)          \
>         id(FIRMWARE_PREALLOC_BUFFER, firmware)  \
>         id(MODULE, kernel-module)               \
>         id(KEXEC_IMAGE, kexec-image)            \
>         id(KEXEC_INITRAMFS, kexec-initramfs)    \
>         id(POLICY, security-policy)             \
>         id(MAX_ID, )
>
>
> #define __fid_enumify(ENUM, dummy) READING_ ## ENUM,
> #define __fid_stringify(dummy, str) #str,
>
> enum kernel_read_file_id {
>         __kernel_read_file_id(__fid_enumify)
> };
>
> extern int kernel_read_file_from_path(char *, void **, loff_t *, loff_t,
>                                       enum kernel_read_file_id);
>
> Are you saying FIRMWARE id is not sufficient ? What would be an example
> purpose be here for FIRMWARE ?

The string "iwlwifi-8265-21.ucode" would be a reasonable purpose, I
think.  It could make sense to split out the vendor, too:

.type = FIRMWARE,
.vendor = "Intel",
.purpose = "iwlwifi-8265-21.ucode",

then distro policy could know to accept a file signed by Intel
(because "Intel" would be mapped in some table to a public key), a
file signed by the distro key where the signature (using PKCS#7
auxiliarry data (or whatever it's called) or some other simpler
protocol) indicates that the signed object is "iwlwifi-8265-21.ucode",
or perhaps an IMA-verified file with an appropriate absolute path.

Mimi, I'm curious: I don't fully understand what is covered by IMA
policy.  How does the IMA kernel_read_file stuff deal with symlinks?
For example, if I symlink /lib/firmware/iwlwifi-8265-21.ucode to
/home/badguy/iwlwifi-8265-21.ucode, what happens?  What if I symlink
/lib/firmware/iwlwifi-8265-21.ucode to /home/badguy/something_else?
Or even /lib/modules/kernel/foo/bar.ko to /home/badguy/evil.ko?  The
interesting case is where the "badguy" user is duly authorized to
write to /home/badguy and holds whatever keys may be needed.

--Andy

Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi

[Luis R. Rodriguez]

On Mon, Aug 01, 2016 at 10:59:57AM -0700, Andy Lutomirski wrote:
> On Mon, Aug 1, 2016 at 10:29 AM, Luis R. Rodriguez <mcgrof@suse.com> wrote:
> > On Sun, Jul 31, 2016 at 11:20:08AM -0700, Andy Lutomirski wrote:
> >> If IMA doesn't want or need to verify the purpose of the loaded file, fine.
> >
> > So other than origin you are indicating a proper LSM that would want to vet firmware
> > should want purpose ? Is that right?
> 
> A security policy that wants to provide strong protection should
> verify that whatever file is being loaded is being used for its
> authorized purpose.  The wireless regulatory subsystem should only
> load data signed by the wifi regulatory key, the iwlwifi driver should
> only accept firmware signed by the system *for the purpose of being
> used as iwlwifi firmware* (or perhaps signed by Intel), the nouveau
> driver should accept files signed for the purpose of being used as
> nvidia firmware and should reject things that are signed by Intel,
> etc.
> 
> > If so I'd like to understand this suggestion
> > a bit better given we already have. So we have:
> >
> > #define __kernel_read_file_id(id) \
> >         id(UNKNOWN, unknown)            \
> >         id(FIRMWARE, firmware)          \
> >         id(FIRMWARE_PREALLOC_BUFFER, firmware)  \
> >         id(MODULE, kernel-module)               \
> >         id(KEXEC_IMAGE, kexec-image)            \
> >         id(KEXEC_INITRAMFS, kexec-initramfs)    \
> >         id(POLICY, security-policy)             \
> >         id(MAX_ID, )
> >
> >
> > #define __fid_enumify(ENUM, dummy) READING_ ## ENUM,
> > #define __fid_stringify(dummy, str) #str,
> >
> > enum kernel_read_file_id {
> >         __kernel_read_file_id(__fid_enumify)
> > };
> >
> > extern int kernel_read_file_from_path(char *, void **, loff_t *, loff_t,
> >                                       enum kernel_read_file_id);
> >
> > Are you saying FIRMWARE id is not sufficient ? What would be an example
> > purpose be here for FIRMWARE ?
> 
> The string "iwlwifi-8265-21.ucode" would be a reasonable purpose, I
> think.  It could make sense to split out the vendor, too:
> 
> .type = FIRMWARE,
> .vendor = "Intel",
> .purpose = "iwlwifi-8265-21.ucode",
> 
> then distro policy could know to accept a file signed by Intel
> (because "Intel" would be mapped in some table to a public key), a
> file signed by the distro key where the signature (using PKCS#7
> auxiliarry data (or whatever it's called) or some other simpler
> protocol) indicates that the signed object is "iwlwifi-8265-21.ucode",
> or perhaps an IMA-verified file with an appropriate absolute path.

OK thanks, this makes it clear.

If you consider the existing kernel strategy for module signing as an LSM
(even though it is not yet), then the way firmware singing was being
designed currently was to match that LSM. That is, we'd have something
very similar to mod_verify_sig() just that when calling
verify_pkcs7_signature() would use VERIFYING_FIRMWARE_SIGNATURE, would
be used instead of VERIFYING_MODULE_SIGNATURE.

We have:

/*                                                                              
 * The use to which an asymmetric key is being put.                             
 */                                                                             
enum key_being_used_for {                                                       
        VERIFYING_MODULE_SIGNATURE,                                             
        VERIFYING_FIRMWARE_SIGNATURE,                                           
        VERIFYING_KEXEC_PE_SIGNATURE,                                           
        VERIFYING_KEY_SIGNATURE,                                                
        VERIFYING_KEY_SELF_SIGNATURE,                                           
        VERIFYING_UNSPECIFIED_SIGNATURE,                                        
        NR__KEY_BEING_USED_FOR                                                  
};    

In this light, what you describe would be an extension to this LSM and am
wondering if we can stage this so this so that this "vendor" and "purpose"
thing is dealt with after the same LSM strategy is matched to module signing
first. With this simple scheme we'd just have one key -- the linux-firmware
maintainer's key.

The second stage of firmware singing would be to iron out if vendors even want
to participate with a series of vendor + firmware file key and we'd have a
registry in the kernel built-in. We'd check then provenance in 2 levels:

  o linux-firmware maintainer key
  o vendor key for the target file

  Luis

Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi

[Andy Lutomirski]

On Mon, Aug 1, 2016 at 1:23 PM, Luis R. Rodriguez <mcgrof@suse.com> wrote:
> On Mon, Aug 01, 2016 at 10:59:57AM -0700, Andy Lutomirski wrote:
>> On Mon, Aug 1, 2016 at 10:29 AM, Luis R. Rodriguez <mcgrof@suse.com> wrote:
>> > On Sun, Jul 31, 2016 at 11:20:08AM -0700, Andy Lutomirski wrote:
>> >> If IMA doesn't want or need to verify the purpose of the loaded file, fine.
>> >
>> > So other than origin you are indicating a proper LSM that would want to vet firmware
>> > should want purpose ? Is that right?
>>
>> A security policy that wants to provide strong protection should
>> verify that whatever file is being loaded is being used for its
>> authorized purpose.  The wireless regulatory subsystem should only
>> load data signed by the wifi regulatory key, the iwlwifi driver should
>> only accept firmware signed by the system *for the purpose of being
>> used as iwlwifi firmware* (or perhaps signed by Intel), the nouveau
>> driver should accept files signed for the purpose of being used as
>> nvidia firmware and should reject things that are signed by Intel,
>> etc.
>>
>> > If so I'd like to understand this suggestion
>> > a bit better given we already have. So we have:
>> >
>> > #define __kernel_read_file_id(id) \
>> >         id(UNKNOWN, unknown)            \
>> >         id(FIRMWARE, firmware)          \
>> >         id(FIRMWARE_PREALLOC_BUFFER, firmware)  \
>> >         id(MODULE, kernel-module)               \
>> >         id(KEXEC_IMAGE, kexec-image)            \
>> >         id(KEXEC_INITRAMFS, kexec-initramfs)    \
>> >         id(POLICY, security-policy)             \
>> >         id(MAX_ID, )
>> >
>> >
>> > #define __fid_enumify(ENUM, dummy) READING_ ## ENUM,
>> > #define __fid_stringify(dummy, str) #str,
>> >
>> > enum kernel_read_file_id {
>> >         __kernel_read_file_id(__fid_enumify)
>> > };
>> >
>> > extern int kernel_read_file_from_path(char *, void **, loff_t *, loff_t,
>> >                                       enum kernel_read_file_id);
>> >
>> > Are you saying FIRMWARE id is not sufficient ? What would be an example
>> > purpose be here for FIRMWARE ?
>>
>> The string "iwlwifi-8265-21.ucode" would be a reasonable purpose, I
>> think.  It could make sense to split out the vendor, too:
>>
>> .type = FIRMWARE,
>> .vendor = "Intel",
>> .purpose = "iwlwifi-8265-21.ucode",
>>
>> then distro policy could know to accept a file signed by Intel
>> (because "Intel" would be mapped in some table to a public key), a
>> file signed by the distro key where the signature (using PKCS#7
>> auxiliarry data (or whatever it's called) or some other simpler
>> protocol) indicates that the signed object is "iwlwifi-8265-21.ucode",
>> or perhaps an IMA-verified file with an appropriate absolute path.
>
> OK thanks, this makes it clear.
>
> If you consider the existing kernel strategy for module signing as an LSM
> (even though it is not yet), then the way firmware singing was being
> designed currently was to match that LSM. That is, we'd have something
> very similar to mod_verify_sig() just that when calling
> verify_pkcs7_signature() would use VERIFYING_FIRMWARE_SIGNATURE, would
> be used instead of VERIFYING_MODULE_SIGNATURE.
>
> We have:
>
> /*
>  * The use to which an asymmetric key is being put.
>  */
> enum key_being_used_for {
>         VERIFYING_MODULE_SIGNATURE,
>         VERIFYING_FIRMWARE_SIGNATURE,
>         VERIFYING_KEXEC_PE_SIGNATURE,
>         VERIFYING_KEY_SIGNATURE,
>         VERIFYING_KEY_SELF_SIGNATURE,
>         VERIFYING_UNSPECIFIED_SIGNATURE,
>         NR__KEY_BEING_USED_FOR
> };
>
> In this light, what you describe would be an extension to this LSM and am
> wondering if we can stage this so this so that this "vendor" and "purpose"
> thing is dealt with after the same LSM strategy is matched to module signing
> first. With this simple scheme we'd just have one key -- the linux-firmware
> maintainer's key.
>

I don't see why not.  After all, nothing is verifying the firmware
name / purpose right not, so nothing would regress.

> The second stage of firmware singing would be to iron out if vendors even want
> to participate with a series of vendor + firmware file key and we'd have a
> registry in the kernel built-in. We'd check then provenance in 2 levels:
>
>   o linux-firmware maintainer key
>   o vendor key for the target file

Given Johannes Berg's request to move regulatory database loading into
the kernel, there might be an earlier use case.  Specifically, either
set up the regulatory database with a vendor of
"linux-wireless-regulatory" and teach the verification code that this
particular vendor *requires* a vendor signature (and not, say, a
distro signature) or allocate it its own enum value for the type and
teach the verification code to work with that.

In any event, consolidating the code so there's a single "verify this
loaded blob" function that implements all the policy would probably
make this easier to write, maintain, and audit.

--Andy

Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi

[Luis R. Rodriguez]

On Mon, Aug 01, 2016 at 01:37:43PM -0700, Andy Lutomirski wrote:
> On Mon, Aug 1, 2016 at 1:23 PM, Luis R. Rodriguez <mcgrof@suse.com> wrote:
> > On Mon, Aug 01, 2016 at 10:59:57AM -0700, Andy Lutomirski wrote:
> >> On Mon, Aug 1, 2016 at 10:29 AM, Luis R. Rodriguez <mcgrof@suse.com> wrote:
> >> > On Sun, Jul 31, 2016 at 11:20:08AM -0700, Andy Lutomirski wrote:
> >> >> If IMA doesn't want or need to verify the purpose of the loaded file, fine.
> >> >
> >> > So other than origin you are indicating a proper LSM that would want to vet firmware
> >> > should want purpose ? Is that right?
> >>
> >> A security policy that wants to provide strong protection should
> >> verify that whatever file is being loaded is being used for its
> >> authorized purpose.  The wireless regulatory subsystem should only
> >> load data signed by the wifi regulatory key, the iwlwifi driver should
> >> only accept firmware signed by the system *for the purpose of being
> >> used as iwlwifi firmware* (or perhaps signed by Intel), the nouveau
> >> driver should accept files signed for the purpose of being used as
> >> nvidia firmware and should reject things that are signed by Intel,
> >> etc.
> >>
> >> > If so I'd like to understand this suggestion
> >> > a bit better given we already have. So we have:
> >> >
> >> > #define __kernel_read_file_id(id) \
> >> >         id(UNKNOWN, unknown)            \
> >> >         id(FIRMWARE, firmware)          \
> >> >         id(FIRMWARE_PREALLOC_BUFFER, firmware)  \
> >> >         id(MODULE, kernel-module)               \
> >> >         id(KEXEC_IMAGE, kexec-image)            \
> >> >         id(KEXEC_INITRAMFS, kexec-initramfs)    \
> >> >         id(POLICY, security-policy)             \
> >> >         id(MAX_ID, )
> >> >
> >> >
> >> > #define __fid_enumify(ENUM, dummy) READING_ ## ENUM,
> >> > #define __fid_stringify(dummy, str) #str,
> >> >
> >> > enum kernel_read_file_id {
> >> >         __kernel_read_file_id(__fid_enumify)
> >> > };
> >> >
> >> > extern int kernel_read_file_from_path(char *, void **, loff_t *, loff_t,
> >> >                                       enum kernel_read_file_id);
> >> >
> >> > Are you saying FIRMWARE id is not sufficient ? What would be an example
> >> > purpose be here for FIRMWARE ?
> >>
> >> The string "iwlwifi-8265-21.ucode" would be a reasonable purpose, I
> >> think.  It could make sense to split out the vendor, too:
> >>
> >> .type = FIRMWARE,
> >> .vendor = "Intel",
> >> .purpose = "iwlwifi-8265-21.ucode",
> >>
> >> then distro policy could know to accept a file signed by Intel
> >> (because "Intel" would be mapped in some table to a public key), a
> >> file signed by the distro key where the signature (using PKCS#7
> >> auxiliarry data (or whatever it's called) or some other simpler
> >> protocol) indicates that the signed object is "iwlwifi-8265-21.ucode",
> >> or perhaps an IMA-verified file with an appropriate absolute path.
> >
> > OK thanks, this makes it clear.
> >
> > If you consider the existing kernel strategy for module signing as an LSM
> > (even though it is not yet), then the way firmware singing was being
> > designed currently was to match that LSM. That is, we'd have something
> > very similar to mod_verify_sig() just that when calling
> > verify_pkcs7_signature() would use VERIFYING_FIRMWARE_SIGNATURE, would
> > be used instead of VERIFYING_MODULE_SIGNATURE.
> >
> > We have:
> >
> > /*
> >  * The use to which an asymmetric key is being put.
> >  */
> > enum key_being_used_for {
> >         VERIFYING_MODULE_SIGNATURE,
> >         VERIFYING_FIRMWARE_SIGNATURE,
> >         VERIFYING_KEXEC_PE_SIGNATURE,
> >         VERIFYING_KEY_SIGNATURE,
> >         VERIFYING_KEY_SELF_SIGNATURE,
> >         VERIFYING_UNSPECIFIED_SIGNATURE,
> >         NR__KEY_BEING_USED_FOR
> > };
> >
> > In this light, what you describe would be an extension to this LSM and am
> > wondering if we can stage this so this so that this "vendor" and "purpose"
> > thing is dealt with after the same LSM strategy is matched to module signing
> > first. With this simple scheme we'd just have one key -- the linux-firmware
> > maintainer's key.
> >
> 
> I don't see why not.  After all, nothing is verifying the firmware
> name / purpose right not, so nothing would regress.

OK then as far as firmware signing is concerned I think this is agreed upon
material.

> > The second stage of firmware singing would be to iron out if vendors even want
> > to participate with a series of vendor + firmware file key and we'd have a
> > registry in the kernel built-in. We'd check then provenance in 2 levels:
> >
> >   o linux-firmware maintainer key
> >   o vendor key for the target file
> 
> Given Johannes Berg's request to move regulatory database loading into
> the kernel, there might be an earlier use case.

I share his goal, and in fact getting rid of needing CRDA was my original
motivation to add firmware signing support. When we reviewed how this would
work -- we seemed to have agreed that Seth (wireless-regdb maintainer) would no
longer need to sign the regulatory.bin file and whatever file we end up with
would instead be signed by Kyle, the linux-firmware maintainer.

> Specifically, either
> set up the regulatory database with a vendor of
> "linux-wireless-regulatory" and teach the verification code that this
> particular vendor *requires* a vendor signature (and not, say, a
> distro signature) or allocate it its own enum value for the type and
> teach the verification code to work with that.

Well reason we ended up deciding on just one key and linux-firmware was
that people already package linux-firmware and we'd hope no one will
put a gun to Kyle's head to do evil things. Nevertheless, what you
describe of augmenting keys for files / purpose seems sensible, however
this should be optional. For our case in 802.11 we seemed to be OK
with Kyle's key last we discussed.

At least for starters.

> In any event, consolidating the code so there's a single "verify this
> loaded blob" function that implements all the policy would probably
> make this easier to write, maintain, and audit.

Agreed. So LSM'ifyng this.

 Luis

Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi

[Andy Lutomirski]

On Mon, Aug 1, 2016 at 1:57 PM, Luis R. Rodriguez <mcgrof@suse.com> wrote:
> On Mon, Aug 01, 2016 at 01:37:43PM -0700, Andy Lutomirski wrote:
>> On Mon, Aug 1, 2016 at 1:23 PM, Luis R. Rodriguez <mcgrof@suse.com> wrote:
>> > The second stage of firmware singing would be to iron out if vendors even want
>> > to participate with a series of vendor + firmware file key and we'd have a
>> > registry in the kernel built-in. We'd check then provenance in 2 levels:
>> >
>> >   o linux-firmware maintainer key
>> >   o vendor key for the target file
>>
>> Given Johannes Berg's request to move regulatory database loading into
>> the kernel, there might be an earlier use case.
>
> I share his goal, and in fact getting rid of needing CRDA was my original
> motivation to add firmware signing support. When we reviewed how this would
> work -- we seemed to have agreed that Seth (wireless-regdb maintainer) would no
> longer need to sign the regulatory.bin file and whatever file we end up with
> would instead be signed by Kyle, the linux-firmware maintainer.

Sounds entirely reasonable.

>
>> Specifically, either
>> set up the regulatory database with a vendor of
>> "linux-wireless-regulatory" and teach the verification code that this
>> particular vendor *requires* a vendor signature (and not, say, a
>> distro signature) or allocate it its own enum value for the type and
>> teach the verification code to work with that.
>
> Well reason we ended up deciding on just one key and linux-firmware was
> that people already package linux-firmware and we'd hope no one will
> put a gun to Kyle's head to do evil things. Nevertheless, what you
> describe of augmenting keys for files / purpose seems sensible, however
> this should be optional. For our case in 802.11 we seemed to be OK
> with Kyle's key last we discussed.

Let me put on my security person / armchair cryptographer hat:

NAK NAK NAK NAK NAK

The 90s are over.  Saying "I threw together this protocol.  It has
these known weaknesses, but I don't think they really matter all that
much." was a pretty bad idea in the nineties (witness SSL2, SSL3, WEP,
etc), and IMNSHO it's simply inexcusable now.

David Howells implemented PKCS7 authenticated attribute support in the
kernel for a reason.  If Kyle will use PKCS7 signatures, get the
authenticated attribute format right and *use it* from day one.  Or he
could use my old suggestion instead: rather than signing the firmware
blob itself, sign a little data structure like this:

struct linux_blob_signed_data {
  unsigned char magic[8];  // "LINUXSIG" -- for domain separation in
case someone messes up
  uint32_t version;  // = 1
  unsigned char sha256[32];  // SHA256 hash of the blob
  uint32_t type;  // what type of thing this is (firmware, etc)
  unsigned char description[];  // the remainder of the structure is
"iwlwifi-whatever.ucode", etc.
};

Then, to verify a signature, the kernel hashes the blob, generates its
own linux_blob_signed_data, memcmps it to the one that Kyle signed
(and rejects if they differ *at all*), and then verifies the
signature.  (Do not try to be clever and parse the supplied
linux_blob_signed_data -- there is a long and storied history of
equivalent ideas being implemented incorrectly, and I can dig out
literature references if you really want.  Just generate your own and
memcmp it, which leaves no room for ambiguity.)

If you're using something other than PKCS7 (which I'd suggest -- PKCS7
is a nasty, ugly, overcomplicated standard), use the struct
linux_blob_signed_data approach.

This is only a few lines of code, and I think there is no excuse for
getting it wrong.  Heck, this would be trivial to implement in pretty
much any scripting language better than bash.

(Sorry to bash your signature thingy, Kyle, but all I'm asking you do
to is either use the fancy pkcs7 openssl options (*gag*) or sign a
trivial data structure instead of the file itself.  If you like, I
hereby offer to write the code if you give me a baseline to work
with.)

--Andy

Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi

[Jason Cooper]

Hey Andy, Luis, Mimi,

On Mon, Aug 01, 2016 at 02:14:52PM -0700, Andy Lutomirski wrote:
> Or he could use my old suggestion instead: rather than signing the
> firmware blob itself, sign a little data structure like this:
> 
> struct linux_blob_signed_data {
>   unsigned char magic[8];  // "LINUXSIG" -- for domain separation in case someone messes up
>   uint32_t version;  // = 1
>   unsigned char sha256[32];  // SHA256 hash of the blob
>   uint32_t type;  // what type of thing this is (firmware, etc)
>   unsigned char description[];  // the remainder of the structure is "iwlwifi-whatever.ucode", etc.
> };

I would include the length of the blob in here as well.

thx,

Jason.

Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi

[Andy Lutomirski]

[-- Attachment #1: Type: text/plain, Size: 1209 bytes --]

On Aug 1, 2016 3:56 PM, "Jason Cooper" <jason@lakedaemon.net> wrote:
>
> Hey Andy, Luis, Mimi,
>
> On Mon, Aug 01, 2016 at 02:14:52PM -0700, Andy Lutomirski wrote:
> > Or he could use my old suggestion instead: rather than signing the
> > firmware blob itself, sign a little data structure like this:
> >
> > struct linux_blob_signed_data {
> >   unsigned char magic[8];  // "LINUXSIG" -- for domain separation in
case someone messes up
> >   uint32_t version;  // = 1
> >   unsigned char sha256[32];  // SHA256 hash of the blob
> >   uint32_t type;  // what type of thing this is (firmware, etc)
> >   unsigned char description[];  // the remainder of the structure is
"iwlwifi-whatever.ucode", etc.
> > };
>
> I would include the length of the blob in here as well.

That's not a bad idea even though length extension doesn't matter here.  If
nothing else, it'll help mitigate silly DoS attacks in which a bad guy
supplies an insanely large blob.  On the other hand, any attacker is
probably root and can easily DoS us no matter what.  It could make the
implementation simpler too, I suppose.

If anyone replaced SHA256 with a boneheaded "hash" like Amazon Glacier's,
then checking the length is necessary.

[-- Attachment #2: Type: text/html, Size: 1560 bytes --]

Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi

[James Bottomley]

On Mon, 2016-08-01 at 14:14 -0700, Andy Lutomirski wrote:
> struct linux_blob_signed_data {
>   unsigned char magic[8];  // "LINUXSIG" -- for domain separation in
> case someone messes up
>   uint32_t version;  // = 1
>   unsigned char sha256[32];  // SHA256 hash of the blob
>   uint32_t type;  // what type of thing this is (firmware, etc)
>   unsigned char description[];  // the remainder of the structure is
> "iwlwifi-whatever.ucode", etc.
> };

Where's the signature in this?  I see a hash but not a signature. 
 However since you NAK'd them: now you're reinventing stuff pkcs7
already has.  pkcs7 has ASN.1 encodings of the hash and the signature,
so no need to repeat it in a non standard way.  In fact, since the
kernel already understands pkcs7, why not just use it (DER encoded). 
 pkcs7 can do an attached and detached signature format, so we could
just simply use it to package signed modules.

James

Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi

[Andy Lutomirski]

[-- Attachment #1: Type: text/plain, Size: 2221 bytes --]

On Aug 1, 2016 5:33 PM, "James Bottomley" <
James.Bottomley@hansenpartnership.com> wrote:
>
> On Mon, 2016-08-01 at 14:14 -0700, Andy Lutomirski wrote:
> > struct linux_blob_signed_data {
> >   unsigned char magic[8];  // "LINUXSIG" -- for domain separation in
> > case someone messes up
> >   uint32_t version;  // = 1
> >   unsigned char sha256[32];  // SHA256 hash of the blob
> >   uint32_t type;  // what type of thing this is (firmware, etc)
> >   unsigned char description[];  // the remainder of the structure is
> > "iwlwifi-whatever.ucode", etc.
> > };
>
> Where's the signature in this?  I see a hash but not a signature.

The whole structure is signed verbatim with your favorite algorithm.

>  However since you NAK'd them: now you're reinventing stuff pkcs7
> already has.  pkcs7 has ASN.1 encodings of the hash and the signature,
> so no need to repeat it in a non standard way.  In fact, since the
> kernel already understands pkcs7, why not just use it (DER encoded).
>  pkcs7 can do an attached and detached signature format, so we could
> just simply use it to package signed modules.

This approach solves none of the problems I'm solving.  Using PKCS#7 with
careful use of "authenticated attributes" does, if you're very careful, as
I mentioned upthread.

But PKCS#7 is a legacy mess, is only compatible with sensible modern
signature algorithms if appropriate ASN.1 bindings exist, is actively
insecure [1], and cannot be replaced by anything else in a drop-in manner
if you use authattrs.

Also, the PKCS#7 parser in the kernel is probably many times larger than a
simple verifier for basically any modern signature scheme.  In contrast, my
scheme is only a couple of lines plus the underlying verifier (RSA PKCS#1
or RSA-PSS or P-256 ECDSA or whatever).  And PKCS#7 isn't even needed for
FIPS compliance AFAIK.

AFAICT the only decent reason for supporting PKCS#7 in the kernel is for
compatibility with some Authenticode thing I never quite figured out the
use of.

[1] The authattr mechanism isn't internally domain-separated, so signatures
with authattrs can be used to generate valid signatures over invalid data.
I think David Howells worked around this in the kernel after I pointed it
out.

[-- Attachment #2: Type: text/html, Size: 2708 bytes --]

Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi

[James Bottomley]

On Mon, 2016-08-01 at 17:48 -0700, Andy Lutomirski wrote:
> On Aug 1, 2016 5:33 PM, "James Bottomley" <
> James.Bottomley@hansenpartnership.com> wrote:
> > 
> > On Mon, 2016-08-01 at 14:14 -0700, Andy Lutomirski wrote:
> > > struct linux_blob_signed_data {
> > >   unsigned char magic[8];  // "LINUXSIG" -- for domain separation
> > > in
> > > case someone messes up
> > >   uint32_t version;  // = 1
> > >   unsigned char sha256[32];  // SHA256 hash of the blob
> > >   uint32_t type;  // what type of thing this is (firmware, etc)
> > >   unsigned char description[];  // the remainder of the structure
> > > is
> > > "iwlwifi-whatever.ucode", etc.
> > > };
> > 
> > Where's the signature in this?  I see a hash but not a signature.
> 
> The whole structure is signed verbatim with your favorite algorithm.

How would you specify which algorithm? if you don't know that you have
a hard time verifying. Or do you mean with a detached PKCS7 signature?

> >  However since you NAK'd them: now you're reinventing stuff pkcs7
> > already has.  pkcs7 has ASN.1 encodings of the hash and the 
> > signature, so no need to repeat it in a non standard way.  In fact, 
> > since the kernel already understands pkcs7, why not just use it 
> > (DER encoded).  pkcs7 can do an attached and detached signature 
> > format, so we could just simply use it to package signed modules.
> 
> This approach solves none of the problems I'm solving.  Using PKCS#7 
> with careful use of "authenticated attributes" does, if you're very
> careful, as I mentioned upthread.
> 
> But PKCS#7 is a legacy mess, is only compatible with sensible modern
> signature algorithms if appropriate ASN.1 bindings exist, is actively
> insecure [1], and cannot be replaced by anything else in a drop-in 
> manner if you use authattrs.

I'm not going to defend ASN.1 or PKCS#7.  The only reason to use it is
that we already have existing tools that can sign and parse it, so we
don't need anything special to sign the modules.  With a hand rolled
header, some tool needs to be built to create it.

> Also, the PKCS#7 parser in the kernel is probably many times larger 
> than a simple verifier for basically any modern signature scheme.  In
> contrast, my scheme is only a couple of lines plus the underlying 
> verifier (RSA PKCS#1 or RSA-PSS or P-256 ECDSA or whatever).  And 
> PKCS#7 isn't even needed for FIPS compliance AFAIK.

Again, don't disagree, but we already have it in the kernel, so it's
now free to use.

> AFAICT the only decent reason for supporting PKCS#7 in the kernel is 
> for compatibility with some Authenticode thing I never quite figured 
> out the use of.

Authenticode is actually microsoft bastardised PKCS7 (if you mean the
authenticode binary signature format).  It's actually the signature of
a hash which uses a MS specific contentType OID.  I'm not entirely
certain we'd ever want to support it in kernel, because it's tied to
the PE-Coff image format.

> [1] The authattr mechanism isn't internally domain-separated, so 
> signatures with authattrs can be used to generate valid signatures 
> over invalid data. I think David Howells worked around this in the 
> kernel after I pointed it out.

How?  The only fiddle I can see you doing is swapping empty attributes
for data and vice versa.

James

Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi

[Andy Lutomirski]

On Mon, Aug 1, 2016 at 6:13 PM, James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
> On Mon, 2016-08-01 at 17:48 -0700, Andy Lutomirski wrote:
>> On Aug 1, 2016 5:33 PM, "James Bottomley" <
>> James.Bottomley@hansenpartnership.com> wrote:
>> >
>> > On Mon, 2016-08-01 at 14:14 -0700, Andy Lutomirski wrote:
>> > > struct linux_blob_signed_data {
>> > >   unsigned char magic[8];  // "LINUXSIG" -- for domain separation
>> > > in
>> > > case someone messes up
>> > >   uint32_t version;  // = 1
>> > >   unsigned char sha256[32];  // SHA256 hash of the blob
>> > >   uint32_t type;  // what type of thing this is (firmware, etc)
>> > >   unsigned char description[];  // the remainder of the structure
>> > > is
>> > > "iwlwifi-whatever.ucode", etc.
>> > > };
>> >
>> > Where's the signature in this?  I see a hash but not a signature.
>>
>> The whole structure is signed verbatim with your favorite algorithm.
>
> How would you specify which algorithm? if you don't know that you have
> a hard time verifying. Or do you mean with a detached PKCS7 signature?

I'm intentionally not specifying this.  The user of the scheme is
responsible for supplying a signed linux_blob_signed_data object.
They can do it however they want (PKCS#7 detached signatures, PKCS#7
non-detached signatures, raw Ed25519 blobs, whatever).  They'll have
to feed this to the kernel somehow along with sufficient information
for the kernel to figure out which key it's supposed to use.  The key
determines the signature algorithm to use.

This isn't much different from PKCS#7 signatures in this regard except
that PKCS#7 give an (awkward) indication of which key to use.  But the
kernel could just as easily try all the keys -- there really shouldn't
be that many.

>
>> >  However since you NAK'd them: now you're reinventing stuff pkcs7
>> > already has.  pkcs7 has ASN.1 encodings of the hash and the
>> > signature, so no need to repeat it in a non standard way.  In fact,
>> > since the kernel already understands pkcs7, why not just use it
>> > (DER encoded).  pkcs7 can do an attached and detached signature
>> > format, so we could just simply use it to package signed modules.
>>
>> This approach solves none of the problems I'm solving.  Using PKCS#7
>> with careful use of "authenticated attributes" does, if you're very
>> careful, as I mentioned upthread.
>>
>> But PKCS#7 is a legacy mess, is only compatible with sensible modern
>> signature algorithms if appropriate ASN.1 bindings exist, is actively
>> insecure [1], and cannot be replaced by anything else in a drop-in
>> manner if you use authattrs.
>
> I'm not going to defend ASN.1 or PKCS#7.  The only reason to use it is
> that we already have existing tools that can sign and parse it, so we
> don't need anything special to sign the modules.  With a hand rolled
> header, some tool needs to be built to create it.

True, but we're really talking about ten lines of code here.

>
>> Also, the PKCS#7 parser in the kernel is probably many times larger
>> than a simple verifier for basically any modern signature scheme.  In
>> contrast, my scheme is only a couple of lines plus the underlying
>> verifier (RSA PKCS#1 or RSA-PSS or P-256 ECDSA or whatever).  And
>> PKCS#7 isn't even needed for FIPS compliance AFAIK.
>
> Again, don't disagree, but we already have it in the kernel, so it's
> now free to use.

But not free to audit :-/

>
>> AFAICT the only decent reason for supporting PKCS#7 in the kernel is
>> for compatibility with some Authenticode thing I never quite figured
>> out the use of.
>
> Authenticode is actually microsoft bastardised PKCS7 (if you mean the
> authenticode binary signature format).  It's actually the signature of
> a hash which uses a MS specific contentType OID.  I'm not entirely
> certain we'd ever want to support it in kernel, because it's tied to
> the PE-Coff image format.

I had the impression that we wanted to support that.  I would have
argued harder against PKCS#7 in kernel if it weren't for that.

>
>> [1] The authattr mechanism isn't internally domain-separated, so
>> signatures with authattrs can be used to generate valid signatures
>> over invalid data. I think David Howells worked around this in the
>> kernel after I pointed it out.
>
> How?  The only fiddle I can see you doing is swapping empty attributes
> for data and vice versa.

Every valid PKCS#7 signature with authattrs is also a valid PKCS#7
without authattrs over a messy ASN.1 object that contains the
authattrs.  They forgot to make the thing that's fed to the raw
signature primitive distinct for the two modes.

--Andy

Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi

[James Bottomley]

On Mon, 2016-08-01 at 18:23 -0700, Andy Lutomirski wrote:
> On Mon, Aug 1, 2016 at 6:13 PM, James Bottomley
> <James.Bottomley@hansenpartnership.com> wrote:
> > On Mon, 2016-08-01 at 17:48 -0700, Andy Lutomirski wrote:
> > > [1] The authattr mechanism isn't internally domain-separated, so
> > > signatures with authattrs can be used to generate valid 
> > > signatures over invalid data. I think David Howells worked around 
> > > this in the kernel after I pointed it out.
> > 
> > How?  The only fiddle I can see you doing is swapping empty 
> > attributes for data and vice versa.
> 
> Every valid PKCS#7 signature with authattrs is also a valid PKCS#7
> without authattrs over a messy ASN.1 object that contains the
> authattrs.  They forgot to make the thing that's fed to the raw
> signature primitive distinct for the two modes.

OK, I accept this, but for PKCS7 signatures, the signing and hashing
algorithms are required to be part of the authenticated attributes, so
this means that if they're missing we know the packet is invalid, so
this attack should be unavailable against signed firmware.

James
 

Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi

[Mimi Zohar]

On Mo, 2016-08-01 at 10:59 -0700, Andy Lutomirski wrote:

> Mimi, I'm curious: I don't fully understand what is covered by IMA
> policy.  How does the IMA kernel_read_file stuff deal with symlinks?
> For example, if I symlink /lib/firmware/iwlwifi-8265-21.ucode to
> /home/badguy/iwlwifi-8265-21.ucode, what happens?  What if I symlink
> /lib/firmware/iwlwifi-8265-21.ucode to /home/badguy/something_else?
> Or even /lib/modules/kernel/foo/bar.ko to /home/badguy/evil.ko?  The
> interesting case is where the "badguy" user is duly authorized to
> write to /home/badguy and holds whatever keys may be needed.

Lets step back a second.  In order for a key to be added to the IMA
keyring, the key must be signed by a key on the builtin keyring.  The
key on the builtin keyring can be compiled into the kernel image or
added post build using Mehmet Kayaalp's patches.

True, any key on the IMA keyring could be used to verify file signatures
(in IMA terminology appraise the file's integrity).  The enumeration is
a first step to making sure that only properly signed code is read by
the kernel.  The next step requires finer grain key management.  In
general, pathname based policies are not a good idea.  Whatever method
is defined, it should not be limited to just firmware or files read by
the kernel, but to all files.

Mimi

Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi

[Andy Lutomirski]

On Mon, Aug 1, 2016 at 3:21 PM, Mimi Zohar <zohar@linux.vnet.ibm.com> wrote:
> On Mo, 2016-08-01 at 10:59 -0700, Andy Lutomirski wrote:
>
>> Mimi, I'm curious: I don't fully understand what is covered by IMA
>> policy.  How does the IMA kernel_read_file stuff deal with symlinks?
>> For example, if I symlink /lib/firmware/iwlwifi-8265-21.ucode to
>> /home/badguy/iwlwifi-8265-21.ucode, what happens?  What if I symlink
>> /lib/firmware/iwlwifi-8265-21.ucode to /home/badguy/something_else?
>> Or even /lib/modules/kernel/foo/bar.ko to /home/badguy/evil.ko?  The
>> interesting case is where the "badguy" user is duly authorized to
>> write to /home/badguy and holds whatever keys may be needed.
>
> Lets step back a second.  In order for a key to be added to the IMA
> keyring, the key must be signed by a key on the builtin keyring.  The
> key on the builtin keyring can be compiled into the kernel image or
> added post build using Mehmet Kayaalp's patches.
>
> True, any key on the IMA keyring could be used to verify file signatures
> (in IMA terminology appraise the file's integrity).  The enumeration is
> a first step to making sure that only properly signed code is read by
> the kernel.  The next step requires finer grain key management.  In
> general, pathname based policies are not a good idea.  Whatever method
> is defined, it should not be limited to just firmware or files read by
> the kernel, but to all files.
>

Unless I'm mistaken (which is quite possible), IMA is primarily
intended to appraise the content of POSIX filesystems.  So, if IMA is
in use, then doing:

$ cat /foo/bar

should only succeed if /foo/bar is signed according to loaded policy.
It's the system administrator's decision what filesystem is actually
mounted at /foo, and root can presumably mess around with application
expectations by, say, bind-mounting something over /foo.

Modules and firmware are special: even root should not be able to
avoid the full signature policy.  This means that, for example:

# mount --bind /evil /lib/firmware

should not result in violating policy.  So the pathname should not be
used as such.  However, firmware is a bit special in that the driver
chooses the pathname to request, and it really does uniquely identify
the intended firmware.  So, when a driver asks for:

"iwlwifi-whatever.ucode"

and the driver core tries to read "/lib/firmware/iwlwifi-whatever.ucode"

it's entirely possible that we'll follow a symlink and end up
elsewhere (Fedora, for example, does exactly this), but the file
that's loaded should be appraised (or verified using a non-IMA means,
etc.) to verify that whatever blob gets found is actually signed by
the holder of an authorized key for the purpose of being used as
"iwlwifi-whatever.ucode".

The current API can't do this cleanly no matter how IMA implements the LSM hook.

--Andy

Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi

[Mimi Zohar]

On Mo, 2016-08-01 at 15:36 -0700, Andy Lutomirski wrote:
> On Mon, Aug 1, 2016 at 3:21 PM, Mimi Zohar <zohar@linux.vnet.ibm.com> wrote:
> > On Mo, 2016-08-01 at 10:59 -0700, Andy Lutomirski wrote:
> >
> >> Mimi, I'm curious: I don't fully understand what is covered by IMA
> >> policy.  How does the IMA kernel_read_file stuff deal with symlinks?
> >> For example, if I symlink /lib/firmware/iwlwifi-8265-21.ucode to
> >> /home/badguy/iwlwifi-8265-21.ucode, what happens?  What if I symlink
> >> /lib/firmware/iwlwifi-8265-21.ucode to /home/badguy/something_else?
> >> Or even /lib/modules/kernel/foo/bar.ko to /home/badguy/evil.ko?  The
> >> interesting case is where the "badguy" user is duly authorized to
> >> write to /home/badguy and holds whatever keys may be needed.
> >
> > Lets step back a second.  In order for a key to be added to the IMA
> > keyring, the key must be signed by a key on the builtin keyring.  The
> > key on the builtin keyring can be compiled into the kernel image or
> > added post build using Mehmet Kayaalp's patches.
> >
> > True, any key on the IMA keyring could be used to verify file signatures
> > (in IMA terminology appraise the file's integrity).  The enumeration is
> > a first step to making sure that only properly signed code is read by
> > the kernel.  The next step requires finer grain key management.  In
> > general, pathname based policies are not a good idea.  Whatever method
> > is defined, it should not be limited to just firmware or files read by
> > the kernel, but to all files.
> >
> 
> Unless I'm mistaken (which is quite possible), IMA is primarily
> intended to appraise the content of POSIX filesystems.  So, if IMA is
> in use, then doing:
> 
> $ cat /foo/bar
> 
> should only succeed if /foo/bar is signed according to loaded policy.
> It's the system administrator's decision what filesystem is actually
> mounted at /foo, and root can presumably mess around with application
> expectations by, say, bind-mounting something over /foo.

The policy does support specifying a UUID to differentiate between file
systems.

> Modules and firmware are special: even root should not be able to
> avoid the full signature policy.  This means that, for example:
> 
> # mount --bind /evil /lib/firmware
> 
> should not result in violating policy.  So the pathname should not be
> used as such.  However, firmware is a bit special in that the driver
> chooses the pathname to request, and it really does uniquely identify
> the intended firmware.  So, when a driver asks for:
> 
> "iwlwifi-whatever.ucode"
> 
> and the driver core tries to read "/lib/firmware/iwlwifi-whatever.ucode"
> 
> it's entirely possible that we'll follow a symlink and end up
> elsewhere (Fedora, for example, does exactly this), but the file
> that's loaded should be appraised (or verified using a non-IMA means,
> etc.) to verify that whatever blob gets found is actually signed by
> the holder of an authorized key for the purpose of being used as
> "iwlwifi-whatever.ucode".

Right, if both /foo/bar and the symlink are validly signed by keys on
the IMA keyring, then either will succeed.  Previously in this thread, I
suggested extending the policy language to explicitly say which keys are
permitted on a per rule basis.

> The current API can't do this cleanly no matter how IMA implements the LSM hook.

I think it is a bit premature to claim that IMA would not be able to
support an extended policy as you describe under any circumstances.

Mimi

Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi

[Jason Cooper]

On Mon, Aug 01, 2016 at 03:36:51PM -0700, Andy Lutomirski wrote:
> On Mon, Aug 1, 2016 at 3:21 PM, Mimi Zohar <zohar@linux.vnet.ibm.com> wrote:
> > On Mo, 2016-08-01 at 10:59 -0700, Andy Lutomirski wrote:
> >
> >> Mimi, I'm curious: I don't fully understand what is covered by IMA
> >> policy.  How does the IMA kernel_read_file stuff deal with symlinks?
> >> For example, if I symlink /lib/firmware/iwlwifi-8265-21.ucode to
> >> /home/badguy/iwlwifi-8265-21.ucode, what happens?  What if I symlink
> >> /lib/firmware/iwlwifi-8265-21.ucode to /home/badguy/something_else?
> >> Or even /lib/modules/kernel/foo/bar.ko to /home/badguy/evil.ko?  The
> >> interesting case is where the "badguy" user is duly authorized to
> >> write to /home/badguy and holds whatever keys may be needed.
> >
> > Lets step back a second.  In order for a key to be added to the IMA
> > keyring, the key must be signed by a key on the builtin keyring.  The
> > key on the builtin keyring can be compiled into the kernel image or
> > added post build using Mehmet Kayaalp's patches.
> >
> > True, any key on the IMA keyring could be used to verify file signatures
> > (in IMA terminology appraise the file's integrity).  The enumeration is
> > a first step to making sure that only properly signed code is read by
> > the kernel.  The next step requires finer grain key management.  In
> > general, pathname based policies are not a good idea.  Whatever method
> > is defined, it should not be limited to just firmware or files read by
> > the kernel, but to all files.
> >
> 
> Unless I'm mistaken (which is quite possible), IMA is primarily
> intended to appraise the content of POSIX filesystems.  So, if IMA is
> in use, then doing:
> 
> $ cat /foo/bar
> 
> should only succeed if /foo/bar is signed according to loaded policy.
> It's the system administrator's decision what filesystem is actually
> mounted at /foo, and root can presumably mess around with application
> expectations by, say, bind-mounting something over /foo.
> 
> Modules and firmware are special: even root should not be able to
> avoid the full signature policy.  This means that, for example:
> 
> # mount --bind /evil /lib/firmware
> 
> should not result in violating policy.  So the pathname should not be
> used as such.  However, firmware is a bit special in that the driver
> chooses the pathname to request, and it really does uniquely identify
> the intended firmware.  So, when a driver asks for:
> 
> "iwlwifi-whatever.ucode"
> 
> and the driver core tries to read "/lib/firmware/iwlwifi-whatever.ucode"
> 
> it's entirely possible that we'll follow a symlink and end up
> elsewhere (Fedora, for example, does exactly this), but the file
> that's loaded should be appraised (or verified using a non-IMA means,
> etc.) to verify that whatever blob gets found is actually signed by
> the holder of an authorized key for the purpose of being used as
> "iwlwifi-whatever.ucode".

Assuming Andy's lightweight signature scheme, it would probably be best
to do a lookup based on the sha256 hash of the file.  Then pathnames
don't matter, and bad files don't even get to the signature checking
code.

thx,

Jason.

Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi

[Andy Lutomirski]

[-- Attachment #1: Type: text/plain, Size: 3463 bytes --]

On Aug 1, 2016 4:04 PM, "Jason Cooper" <jason@lakedaemon.net> wrote:
>
> On Mon, Aug 01, 2016 at 03:36:51PM -0700, Andy Lutomirski wrote:
> > On Mon, Aug 1, 2016 at 3:21 PM, Mimi Zohar <zohar@linux.vnet.ibm.com>
wrote:
> > > On Mo, 2016-08-01 at 10:59 -0700, Andy Lutomirski wrote:
> > >
> > >> Mimi, I'm curious: I don't fully understand what is covered by IMA
> > >> policy.  How does the IMA kernel_read_file stuff deal with symlinks?
> > >> For example, if I symlink /lib/firmware/iwlwifi-8265-21.ucode to
> > >> /home/badguy/iwlwifi-8265-21.ucode, what happens?  What if I symlink
> > >> /lib/firmware/iwlwifi-8265-21.ucode to /home/badguy/something_else?
> > >> Or even /lib/modules/kernel/foo/bar.ko to /home/badguy/evil.ko?  The
> > >> interesting case is where the "badguy" user is duly authorized to
> > >> write to /home/badguy and holds whatever keys may be needed.
> > >
> > > Lets step back a second.  In order for a key to be added to the IMA
> > > keyring, the key must be signed by a key on the builtin keyring.  The
> > > key on the builtin keyring can be compiled into the kernel image or
> > > added post build using Mehmet Kayaalp's patches.
> > >
> > > True, any key on the IMA keyring could be used to verify file
signatures
> > > (in IMA terminology appraise the file's integrity).  The enumeration
is
> > > a first step to making sure that only properly signed code is read by
> > > the kernel.  The next step requires finer grain key management.  In
> > > general, pathname based policies are not a good idea.  Whatever method
> > > is defined, it should not be limited to just firmware or files read by
> > > the kernel, but to all files.
> > >
> >
> > Unless I'm mistaken (which is quite possible), IMA is primarily
> > intended to appraise the content of POSIX filesystems.  So, if IMA is
> > in use, then doing:
> >
> > $ cat /foo/bar
> >
> > should only succeed if /foo/bar is signed according to loaded policy.
> > It's the system administrator's decision what filesystem is actually
> > mounted at /foo, and root can presumably mess around with application
> > expectations by, say, bind-mounting something over /foo.
> >
> > Modules and firmware are special: even root should not be able to
> > avoid the full signature policy.  This means that, for example:
> >
> > # mount --bind /evil /lib/firmware
> >
> > should not result in violating policy.  So the pathname should not be
> > used as such.  However, firmware is a bit special in that the driver
> > chooses the pathname to request, and it really does uniquely identify
> > the intended firmware.  So, when a driver asks for:
> >
> > "iwlwifi-whatever.ucode"
> >
> > and the driver core tries to read "/lib/firmware/iwlwifi-whatever.ucode"
> >
> > it's entirely possible that we'll follow a symlink and end up
> > elsewhere (Fedora, for example, does exactly this), but the file
> > that's loaded should be appraised (or verified using a non-IMA means,
> > etc.) to verify that whatever blob gets found is actually signed by
> > the holder of an authorized key for the purpose of being used as
> > "iwlwifi-whatever.ucode".
>
> Assuming Andy's lightweight signature scheme, it would probably be best
> to do a lookup based on the sha256 hash of the file.  Then pathnames
> don't matter, and bad files don't even get to the signature checking
> code.
>

I'm not sure I understand what you mean.  What table would we look the hash
up in?  What are we finding in that table?

[-- Attachment #2: Type: text/html, Size: 4531 bytes --]

Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi

[Jason Cooper]

On Mon, Aug 01, 2016 at 04:13:50PM -0700, Andy Lutomirski wrote:
> On Aug 1, 2016 4:04 PM, "Jason Cooper" <jason@lakedaemon.net> wrote:
> >
> > On Mon, Aug 01, 2016 at 03:36:51PM -0700, Andy Lutomirski wrote:
> > > On Mon, Aug 1, 2016 at 3:21 PM, Mimi Zohar <zohar@linux.vnet.ibm.com>
> wrote:
> > > > On Mo, 2016-08-01 at 10:59 -0700, Andy Lutomirski wrote:
> > > >
> > > >> Mimi, I'm curious: I don't fully understand what is covered by IMA
> > > >> policy.  How does the IMA kernel_read_file stuff deal with symlinks?
> > > >> For example, if I symlink /lib/firmware/iwlwifi-8265-21.ucode to
> > > >> /home/badguy/iwlwifi-8265-21.ucode, what happens?  What if I symlink
> > > >> /lib/firmware/iwlwifi-8265-21.ucode to /home/badguy/something_else?
> > > >> Or even /lib/modules/kernel/foo/bar.ko to /home/badguy/evil.ko?  The
> > > >> interesting case is where the "badguy" user is duly authorized to
> > > >> write to /home/badguy and holds whatever keys may be needed.
> > > >
> > > > Lets step back a second.  In order for a key to be added to the IMA
> > > > keyring, the key must be signed by a key on the builtin keyring.  The
> > > > key on the builtin keyring can be compiled into the kernel image or
> > > > added post build using Mehmet Kayaalp's patches.
> > > >
> > > > True, any key on the IMA keyring could be used to verify file
> signatures
> > > > (in IMA terminology appraise the file's integrity).  The enumeration
> is
> > > > a first step to making sure that only properly signed code is read by
> > > > the kernel.  The next step requires finer grain key management.  In
> > > > general, pathname based policies are not a good idea.  Whatever method
> > > > is defined, it should not be limited to just firmware or files read by
> > > > the kernel, but to all files.
> > > >
> > >
> > > Unless I'm mistaken (which is quite possible), IMA is primarily
> > > intended to appraise the content of POSIX filesystems.  So, if IMA is
> > > in use, then doing:
> > >
> > > $ cat /foo/bar
> > >
> > > should only succeed if /foo/bar is signed according to loaded policy.
> > > It's the system administrator's decision what filesystem is actually
> > > mounted at /foo, and root can presumably mess around with application
> > > expectations by, say, bind-mounting something over /foo.
> > >
> > > Modules and firmware are special: even root should not be able to
> > > avoid the full signature policy.  This means that, for example:
> > >
> > > # mount --bind /evil /lib/firmware
> > >
> > > should not result in violating policy.  So the pathname should not be
> > > used as such.  However, firmware is a bit special in that the driver
> > > chooses the pathname to request, and it really does uniquely identify
> > > the intended firmware.  So, when a driver asks for:
> > >
> > > "iwlwifi-whatever.ucode"
> > >
> > > and the driver core tries to read "/lib/firmware/iwlwifi-whatever.ucode"
> > >
> > > it's entirely possible that we'll follow a symlink and end up
> > > elsewhere (Fedora, for example, does exactly this), but the file
> > > that's loaded should be appraised (or verified using a non-IMA means,
> > > etc.) to verify that whatever blob gets found is actually signed by
> > > the holder of an authorized key for the purpose of being used as
> > > "iwlwifi-whatever.ucode".
> >
> > Assuming Andy's lightweight signature scheme, it would probably be best
> > to do a lookup based on the sha256 hash of the file.  Then pathnames
> > don't matter, and bad files don't even get to the signature checking
> > code.
> >
> 
> I'm not sure I understand what you mean.  What table would we look the hash
> up in?  What are we finding in that table?

>From the other subthread:

> Then, to verify a signature, the kernel hashes the blob, generates its
> own linux_blob_signed_data, memcmps it to the one that Kyle signed
> (and rejects if they differ *at all*), and then verifies the
> signature.  (Do not try to be clever and parse the supplied
> linux_blob_signed_data -- there is a long and storied history of
> equivalent ideas being implemented incorrectly, and I can dig out
> literature references if you really want.  Just generate your own and
> memcmp it, which leaves no room for ambiguity.)
> 

So, I'm suggesting that when "the kernel hashes the blob", it use that
hash to locate *which* "Kyle-signed" linux_blob_signed_data it needs to
compare against.  That's all, just removing the filename from the
equation. :-)

thx,

Jason.

Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi

[Andy Lutomirski]

[-- Attachment #1: Type: text/plain, Size: 5008 bytes --]

On Aug 1, 2016 4:30 PM, "Jason Cooper" <jason@lakedaemon.net> wrote:
>
> On Mon, Aug 01, 2016 at 04:13:50PM -0700, Andy Lutomirski wrote:
> > On Aug 1, 2016 4:04 PM, "Jason Cooper" <jason@lakedaemon.net> wrote:
> > >
> > > On Mon, Aug 01, 2016 at 03:36:51PM -0700, Andy Lutomirski wrote:
> > > > On Mon, Aug 1, 2016 at 3:21 PM, Mimi Zohar <zohar@linux.vnet.ibm.com
>
> > wrote:
> > > > > On Mo, 2016-08-01 at 10:59 -0700, Andy Lutomirski wrote:
> > > > >
> > > > >> Mimi, I'm curious: I don't fully understand what is covered by
IMA
> > > > >> policy.  How does the IMA kernel_read_file stuff deal with
symlinks?
> > > > >> For example, if I symlink /lib/firmware/iwlwifi-8265-21.ucode to
> > > > >> /home/badguy/iwlwifi-8265-21.ucode, what happens?  What if I
symlink
> > > > >> /lib/firmware/iwlwifi-8265-21.ucode to
/home/badguy/something_else?
> > > > >> Or even /lib/modules/kernel/foo/bar.ko to /home/badguy/evil.ko?
The
> > > > >> interesting case is where the "badguy" user is duly authorized to
> > > > >> write to /home/badguy and holds whatever keys may be needed.
> > > > >
> > > > > Lets step back a second.  In order for a key to be added to the
IMA
> > > > > keyring, the key must be signed by a key on the builtin keyring.
The
> > > > > key on the builtin keyring can be compiled into the kernel image
or
> > > > > added post build using Mehmet Kayaalp's patches.
> > > > >
> > > > > True, any key on the IMA keyring could be used to verify file
> > signatures
> > > > > (in IMA terminology appraise the file's integrity).  The
enumeration
> > is
> > > > > a first step to making sure that only properly signed code is
read by
> > > > > the kernel.  The next step requires finer grain key management.
In
> > > > > general, pathname based policies are not a good idea.  Whatever
method
> > > > > is defined, it should not be limited to just firmware or files
read by
> > > > > the kernel, but to all files.
> > > > >
> > > >
> > > > Unless I'm mistaken (which is quite possible), IMA is primarily
> > > > intended to appraise the content of POSIX filesystems.  So, if IMA
is
> > > > in use, then doing:
> > > >
> > > > $ cat /foo/bar
> > > >
> > > > should only succeed if /foo/bar is signed according to loaded
policy.
> > > > It's the system administrator's decision what filesystem is actually
> > > > mounted at /foo, and root can presumably mess around with
application
> > > > expectations by, say, bind-mounting something over /foo.
> > > >
> > > > Modules and firmware are special: even root should not be able to
> > > > avoid the full signature policy.  This means that, for example:
> > > >
> > > > # mount --bind /evil /lib/firmware
> > > >
> > > > should not result in violating policy.  So the pathname should not
be
> > > > used as such.  However, firmware is a bit special in that the driver
> > > > chooses the pathname to request, and it really does uniquely
identify
> > > > the intended firmware.  So, when a driver asks for:
> > > >
> > > > "iwlwifi-whatever.ucode"
> > > >
> > > > and the driver core tries to read
"/lib/firmware/iwlwifi-whatever.ucode"
> > > >
> > > > it's entirely possible that we'll follow a symlink and end up
> > > > elsewhere (Fedora, for example, does exactly this), but the file
> > > > that's loaded should be appraised (or verified using a non-IMA
means,
> > > > etc.) to verify that whatever blob gets found is actually signed by
> > > > the holder of an authorized key for the purpose of being used as
> > > > "iwlwifi-whatever.ucode".
> > >
> > > Assuming Andy's lightweight signature scheme, it would probably be
best
> > > to do a lookup based on the sha256 hash of the file.  Then pathnames
> > > don't matter, and bad files don't even get to the signature checking
> > > code.
> > >
> >
> > I'm not sure I understand what you mean.  What table would we look the
hash
> > up in?  What are we finding in that table?
>
> From the other subthread:
>
> > Then, to verify a signature, the kernel hashes the blob, generates its
> > own linux_blob_signed_data, memcmps it to the one that Kyle signed
> > (and rejects if they differ *at all*), and then verifies the
> > signature.  (Do not try to be clever and parse the supplied
> > linux_blob_signed_data -- there is a long and storied history of
> > equivalent ideas being implemented incorrectly, and I can dig out
> > literature references if you really want.  Just generate your own and
> > memcmp it, which leaves no room for ambiguity.)
> >
>
> So, I'm suggesting that when "the kernel hashes the blob", it use that
> hash to locate *which* "Kyle-signed" linux_blob_signed_data it needs to
> compare against.  That's all, just removing the filename from the
> equation. :-)

So Kyle would generate a list of signatures indexed by the blob's hash
instead of generating things like "iwlwifi-whatever.ucode.sig"?  Seems
okay.  It'll keep the existing hooks working, I think.  Of course, we still
need to check the "iwlwifi-whatever.ucode" bit to confirm that it matches
Kyle's signed data.

[-- Attachment #2: Type: text/html, Size: 6850 bytes --]

Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi

[Jason Cooper]

Morning Andy,

On Mon, Aug 01, 2016 at 04:45:20PM -0700, Andy Lutomirski wrote:
> On Aug 1, 2016 4:30 PM, "Jason Cooper" <jason@lakedaemon.net> wrote:
> > On Mon, Aug 01, 2016 at 04:13:50PM -0700, Andy Lutomirski wrote:
> > > On Aug 1, 2016 4:04 PM, "Jason Cooper" <jason@lakedaemon.net> wrote:
...
> > > > Assuming Andy's lightweight signature scheme, it would probably be best
> > > > to do a lookup based on the sha256 hash of the file.  Then pathnames
> > > > don't matter, and bad files don't even get to the signature checking
> > > > code.
> > > >
> > >
> > > I'm not sure I understand what you mean.  What table would we look the hash
> > > up in?  What are we finding in that table?
> >
> > From the other subthread:
> >
> > > Then, to verify a signature, the kernel hashes the blob, generates its
> > > own linux_blob_signed_data, memcmps it to the one that Kyle signed
> > > (and rejects if they differ *at all*), and then verifies the
> > > signature.  (Do not try to be clever and parse the supplied
> > > linux_blob_signed_data -- there is a long and storied history of
> > > equivalent ideas being implemented incorrectly, and I can dig out
> > > literature references if you really want.  Just generate your own and
> > > memcmp it, which leaves no room for ambiguity.)
> > >
> >
> > So, I'm suggesting that when "the kernel hashes the blob", it use that
> > hash to locate *which* "Kyle-signed" linux_blob_signed_data it needs to
> > compare against.  That's all, just removing the filename from the
> > equation. :-)
> 
> So Kyle would generate a list of signatures indexed by the blob's hash
> instead of generating things like "iwlwifi-whatever.ucode.sig"?  Seems
> okay.  It'll keep the existing hooks working, I think.  Of course, we still
> need to check the "iwlwifi-whatever.ucode" bit to confirm that it matches
> Kyle's signed data.

Right.  That's where it may be better to use a version string, say the
sha1 from linux-firmware.git, or the upstream version number.  However,
that route means we can't easily 'build our own linux_blob_signed_data
and do a memcmp.' since userspace may not have that info handy.

It's almost as if we need some *unsigned* attributes that are purely
informative.  So we can dump a message in the logs:

  Loaded /lib/firmware/intel/iwlwifi-whatever.ucode., signature match for 'iwlwifi-20160711.ucode', signed by "Intel, Corp" RSA4096 key with
keyid <sha256>.

The first path is the actual location and name of the file, and the
second is the filename attribute that is a hint, but we don't depend on
it for matching or verification.

thx,

Jason.

Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi

[Andy Lutomirski]

[-- Attachment #1: Type: text/plain, Size: 3533 bytes --]

On Aug 2, 2016 5:20 AM, "Jason Cooper" <jason@lakedaemon.net> wrote:
>
> Morning Andy,
>
> On Mon, Aug 01, 2016 at 04:45:20PM -0700, Andy Lutomirski wrote:
> > On Aug 1, 2016 4:30 PM, "Jason Cooper" <jason@lakedaemon.net> wrote:
> > > On Mon, Aug 01, 2016 at 04:13:50PM -0700, Andy Lutomirski wrote:
> > > > On Aug 1, 2016 4:04 PM, "Jason Cooper" <jason@lakedaemon.net> wrote:
> ...
> > > > > Assuming Andy's lightweight signature scheme, it would probably
be best
> > > > > to do a lookup based on the sha256 hash of the file.  Then
pathnames
> > > > > don't matter, and bad files don't even get to the signature
checking
> > > > > code.
> > > > >
> > > >
> > > > I'm not sure I understand what you mean.  What table would we look
the hash
> > > > up in?  What are we finding in that table?
> > >
> > > From the other subthread:
> > >
> > > > Then, to verify a signature, the kernel hashes the blob, generates
its
> > > > own linux_blob_signed_data, memcmps it to the one that Kyle signed
> > > > (and rejects if they differ *at all*), and then verifies the
> > > > signature.  (Do not try to be clever and parse the supplied
> > > > linux_blob_signed_data -- there is a long and storied history of
> > > > equivalent ideas being implemented incorrectly, and I can dig out
> > > > literature references if you really want.  Just generate your own
and
> > > > memcmp it, which leaves no room for ambiguity.)
> > > >
> > >
> > > So, I'm suggesting that when "the kernel hashes the blob", it use that
> > > hash to locate *which* "Kyle-signed" linux_blob_signed_data it needs
to
> > > compare against.  That's all, just removing the filename from the
> > > equation. :-)
> >
> > So Kyle would generate a list of signatures indexed by the blob's hash
> > instead of generating things like "iwlwifi-whatever.ucode.sig"?  Seems
> > okay.  It'll keep the existing hooks working, I think.  Of course, we
still
> > need to check the "iwlwifi-whatever.ucode" bit to confirm that it
matches
> > Kyle's signed data.
>
> Right.  That's where it may be better to use a version string, say the
> sha1 from linux-firmware.git, or the upstream version number.  However,
> that route means we can't easily 'build our own linux_blob_signed_data
> and do a memcmp.' since userspace may not have that info handy.

I don't think I agree, although iwlwifi may not be the best example.

The driver will say request_firmware("iwlwifi-whatever.ucode", ...,
"Intel") or similar.  The distro compiles the driver.  Afterwards, Intel
releases an updated, backwards-compatible blob.

If root trusts Intel, root can install that blob along with Kyle or Intel's
signature, and the kernel should accept it.  We can achieve this by Kyle
signing the whole struct *and providing the signed struct* or by Intel
doing the equivalent operation.

But we do need the kernel to verify the "iwlwifi-whatever.ucode" string to
prevent an attack in which someone does:

cp other-signed-thing.ucode iwlwifi-whatever.ucode

and thus causes the driver to upload something harmful to the card.  The
reason the textual firmware name works here (for using Kyle's signature and
for distro signatures) is that the string does uniquely define the firmware
purpose for Linux.

If needed for vendor relations, we could accept an alternate format for
vendor keys.  In that case, we avoid the wrong-blob attack by checking that
the key we verify with matches the expected vendor and hope that the vendor
doesn't release two pieces of hardware with firmwares that damage or attack
each other.

[-- Attachment #2: Type: text/html, Size: 4621 bytes --]

Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi

[Jason Cooper]

Hi Andy,

On Tue, Aug 02, 2016 at 08:07:17AM -0700, Andy Lutomirski wrote:
> On Aug 2, 2016 5:20 AM, "Jason Cooper" <jason@lakedaemon.net> wrote:
> > On Mon, Aug 01, 2016 at 04:45:20PM -0700, Andy Lutomirski wrote:
> > > On Aug 1, 2016 4:30 PM, "Jason Cooper" <jason@lakedaemon.net> wrote:
> > > > On Mon, Aug 01, 2016 at 04:13:50PM -0700, Andy Lutomirski wrote:
> > > > > On Aug 1, 2016 4:04 PM, "Jason Cooper" <jason@lakedaemon.net> wrote:
> > ...
> > > > > > Assuming Andy's lightweight signature scheme, it would probably be best
> > > > > > to do a lookup based on the sha256 hash of the file.  Then pathnames
> > > > > > don't matter, and bad files don't even get to the signature checking
> > > > > > code.
> > > > > >
> > > > >
> > > > > I'm not sure I understand what you mean.  What table would we look the hash
> > > > > up in?  What are we finding in that table?
> > > >
> > > > From the other subthread:
> > > >
> > > > > Then, to verify a signature, the kernel hashes the blob, generates its
> > > > > own linux_blob_signed_data, memcmps it to the one that Kyle signed
> > > > > (and rejects if they differ *at all*), and then verifies the
> > > > > signature.  (Do not try to be clever and parse the supplied
> > > > > linux_blob_signed_data -- there is a long and storied history of
> > > > > equivalent ideas being implemented incorrectly, and I can dig out
> > > > > literature references if you really want.  Just generate your own and
> > > > > memcmp it, which leaves no room for ambiguity.)
> > > > >
> > > >
> > > > So, I'm suggesting that when "the kernel hashes the blob", it use that
> > > > hash to locate *which* "Kyle-signed" linux_blob_signed_data it needs to
> > > > compare against.  That's all, just removing the filename from the
> > > > equation. :-)
> > >
> > > So Kyle would generate a list of signatures indexed by the blob's hash
> > > instead of generating things like "iwlwifi-whatever.ucode.sig"?  Seems
> > > okay.  It'll keep the existing hooks working, I think.  Of course, we still
> > > need to check the "iwlwifi-whatever.ucode" bit to confirm that it matches
> > > Kyle's signed data.
> >
> > Right.  That's where it may be better to use a version string, say the
> > sha1 from linux-firmware.git, or the upstream version number.  However,
> > that route means we can't easily 'build our own linux_blob_signed_data
> > and do a memcmp.' since userspace may not have that info handy.
> 
> I don't think I agree, although iwlwifi may not be the best example.

merf.  No, that was a half-baked idea (version numbers and such).

> The driver will say request_firmware("iwlwifi-whatever.ucode", ...,
> "Intel") or similar.  The distro compiles the driver.  Afterwards, Intel
> releases an updated, backwards-compatible blob.
> 
> If root trusts Intel, root can install that blob along with Kyle or Intel's
> signature, and the kernel should accept it.  We can achieve this by Kyle
> signing the whole struct *and providing the signed struct* or by Intel
> doing the equivalent operation.

I agree, but aren't a lot of the files in linux-firmware hex dumps?
meaning that 'compiling' is just reverting them to binary.  Almost akin
to a deterministic build.  Intel's signature should still verify.

Having Kyle's signature adds weight since an after-the-fact attacker
would have to compromise two locations instead of just one.

> But we do need the kernel to verify the "iwlwifi-whatever.ucode" string to
> prevent an attack in which someone does:
> 
> cp other-signed-thing.ucode iwlwifi-whatever.ucode

How so?  The sha256 of the blob won't match, the signature will fail.

And besides, you seems to be saying the kernel needs to verify the
filename, yet the command you give spoofs that filename...  You seem to
be proving *my* point ;-)

> and thus causes the driver to upload something harmful to the card.  The
> reason the textual firmware name works here (for using Kyle's signature and
> for distro signatures) is that the string does uniquely define the firmware
> purpose for Linux.

Back to my earlier suggestion: The sha256 hash of the blob uniquely
identifies the blob, and gives us a more flexible system.  We care about
the blob, not the name.  git does the same thing, but with sha1.

We can still happily use the filename in the request_firmware() call,
it's just an untrusted fs lookup string.  Ultimately, it's the hash of the
blob that matters.

> If needed for vendor relations, we could accept an alternate format for
> vendor keys.  In that case, we avoid the wrong-blob attack by checking that
> the key we verify with matches the expected vendor and hope that the vendor
> doesn't release two pieces of hardware with firmwares that damage or attack
> each other.

-EPARSE.

thx,

Jason.

Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi

[Andy Lutomirski]

On Wed, Aug 3, 2016 at 9:44 AM, Jason Cooper <jason@lakedaemon.net> wrote:
> Hi Andy,
>
> On Tue, Aug 02, 2016 at 08:07:17AM -0700, Andy Lutomirski wrote:
>> On Aug 2, 2016 5:20 AM, "Jason Cooper" <jason@lakedaemon.net> wrote:
>> > On Mon, Aug 01, 2016 at 04:45:20PM -0700, Andy Lutomirski wrote:
>> > > On Aug 1, 2016 4:30 PM, "Jason Cooper" <jason@lakedaemon.net> wrote:
>> > > > On Mon, Aug 01, 2016 at 04:13:50PM -0700, Andy Lutomirski wrote:
>> > > > > On Aug 1, 2016 4:04 PM, "Jason Cooper" <jason@lakedaemon.net> wrote:
>> > ...
>> > > > > > Assuming Andy's lightweight signature scheme, it would probably be best
>> > > > > > to do a lookup based on the sha256 hash of the file.  Then pathnames
>> > > > > > don't matter, and bad files don't even get to the signature checking
>> > > > > > code.
>> > > > > >
>> > > > >
>> > > > > I'm not sure I understand what you mean.  What table would we look the hash
>> > > > > up in?  What are we finding in that table?
>> > > >
>> > > > From the other subthread:
>> > > >
>> > > > > Then, to verify a signature, the kernel hashes the blob, generates its
>> > > > > own linux_blob_signed_data, memcmps it to the one that Kyle signed
>> > > > > (and rejects if they differ *at all*), and then verifies the
>> > > > > signature.  (Do not try to be clever and parse the supplied
>> > > > > linux_blob_signed_data -- there is a long and storied history of
>> > > > > equivalent ideas being implemented incorrectly, and I can dig out
>> > > > > literature references if you really want.  Just generate your own and
>> > > > > memcmp it, which leaves no room for ambiguity.)
>> > > > >
>> > > >
>> > > > So, I'm suggesting that when "the kernel hashes the blob", it use that
>> > > > hash to locate *which* "Kyle-signed" linux_blob_signed_data it needs to
>> > > > compare against.  That's all, just removing the filename from the
>> > > > equation. :-)
>> > >
>> > > So Kyle would generate a list of signatures indexed by the blob's hash
>> > > instead of generating things like "iwlwifi-whatever.ucode.sig"?  Seems
>> > > okay.  It'll keep the existing hooks working, I think.  Of course, we still
>> > > need to check the "iwlwifi-whatever.ucode" bit to confirm that it matches
>> > > Kyle's signed data.
>> >
>> > Right.  That's where it may be better to use a version string, say the
>> > sha1 from linux-firmware.git, or the upstream version number.  However,
>> > that route means we can't easily 'build our own linux_blob_signed_data
>> > and do a memcmp.' since userspace may not have that info handy.
>>
>> I don't think I agree, although iwlwifi may not be the best example.
>
> merf.  No, that was a half-baked idea (version numbers and such).
>
>> The driver will say request_firmware("iwlwifi-whatever.ucode", ...,
>> "Intel") or similar.  The distro compiles the driver.  Afterwards, Intel
>> releases an updated, backwards-compatible blob.
>>
>> If root trusts Intel, root can install that blob along with Kyle or Intel's
>> signature, and the kernel should accept it.  We can achieve this by Kyle
>> signing the whole struct *and providing the signed struct* or by Intel
>> doing the equivalent operation.
>
> I agree, but aren't a lot of the files in linux-firmware hex dumps?
> meaning that 'compiling' is just reverting them to binary.  Almost akin
> to a deterministic build.  Intel's signature should still verify.
>
> Having Kyle's signature adds weight since an after-the-fact attacker
> would have to compromise two locations instead of just one.

I don't think that most vendors supply signatures right now, though.

>
>> But we do need the kernel to verify the "iwlwifi-whatever.ucode" string to
>> prevent an attack in which someone does:
>>
>> cp other-signed-thing.ucode iwlwifi-whatever.ucode
>
> How so?  The sha256 of the blob won't match, the signature will fail.
>

I'm assuming the attacker has the ability to validly sign
other-signed-thing.ucode.  For example, suppose that Eviltel wanted to
compromise Intel hardware and released a firmware blob that worked
correctly on Eviltel hardware but did bad things if loaded into an
Intel card.  The verification scheme should prevent Kyle's signature
on the Eviltel blob from being abused to load it into the Intel
device.

> And besides, you seems to be saying the kernel needs to verify the
> filename, yet the command you give spoofs that filename...  You seem to
> be proving *my* point ;-)

?

I'm saying that my attack should fail because the kernel should verify
that Kyle signed a message saying "the blob with has xyz is okay to
use for drivers that request 'other-signed-thing.ucode'".  Drivers
that request 'iwlwifi-whatever.ucode' won't accept that.

>
>> and thus causes the driver to upload something harmful to the card.  The
>> reason the textual firmware name works here (for using Kyle's signature and
>> for distro signatures) is that the string does uniquely define the firmware
>> purpose for Linux.
>
> Back to my earlier suggestion: The sha256 hash of the blob uniquely
> identifies the blob, and gives us a more flexible system.  We care about
> the blob, not the name.  git does the same thing, but with sha1.
>
> We can still happily use the filename in the request_firmware() call,
> it's just an untrusted fs lookup string.  Ultimately, it's the hash of the
> blob that matters.

But this is vulnerable to exactly the attack above, right?

To clarify, I'm not saying I care at all about the actual on-disk name
of the file.  I'm saying that I think Kyle should sign something that
includes the literal string passed to request_firmware, as that string
defines the intended purpose of the blob.  In most cases, they happen
to be the same string.

>
>> If needed for vendor relations, we could accept an alternate format for
>> vendor keys.  In that case, we avoid the wrong-blob attack by checking that
>> the key we verify with matches the expected vendor and hope that the vendor
>> doesn't release two pieces of hardware with firmwares that damage or attack
>> each other.
>
> -EPARSE.

What I mean is: Kyle would sign a structure defined by the kernel, but
if necessary would also accept a different signature format from a
hardware vendor if the vendor wanted us to.

Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi

[Jason Cooper]

On Wed, Aug 03, 2016 at 10:20:17AM -0700, Andy Lutomirski wrote:
> On Wed, Aug 3, 2016 at 9:44 AM, Jason Cooper <jason@lakedaemon.net> wrote:
> > On Tue, Aug 02, 2016 at 08:07:17AM -0700, Andy Lutomirski wrote:
...
> >> But we do need the kernel to verify the "iwlwifi-whatever.ucode" string to
> >> prevent an attack in which someone does:
> >>
> >> cp other-signed-thing.ucode iwlwifi-whatever.ucode
> >
> > How so?  The sha256 of the blob won't match, the signature will fail.
> >
> 
> I'm assuming the attacker has the ability to validly sign
> other-signed-thing.ucode.  For example, suppose that Eviltel wanted to
> compromise Intel hardware and released a firmware blob that worked
> correctly on Eviltel hardware but did bad things if loaded into an
> Intel card.  The verification scheme should prevent Kyle's signature
> on the Eviltel blob from being abused to load it into the Intel
> device.

Ah, now I see.  I was missing the Eviltel bit. ;-)  So you're attempting
to mitigate one of the key weaknesses of the CA system.  I still don't
think the filename is the correct mechanism for what you're trying to
do.  Although, I agree that it does need to be addressed and mitigated.

Perhaps the PCI ids and USB ids would be a better discriminator?  So,
your signature struct would contain one or more vendor/product
identifiers for which the signed blob is valid.  On embedded, the
devicetree compatible string may be sufficient for non-discoverable
busses.

In a realistic scenario, I could see Intel just signing the firmware,
then 'we' counter-sign with the added metadata restricting the firmware
to a specific subset of devices.  iow, we need to make sure to separate
veracity "Intel did create this" from policy "Debian/LKML says this
firmware should only be loaded into [device list]"

thx,

Jason.

Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi

[Luis R. Rodriguez]

On Sun, Jul 31, 2016 at 09:19:28AM -0700, Andy Lutomirski wrote:
> Also, are there any plans to move module signature verification into
> .kernel_post_read_file?

That's a question for David, but from what I gather and as I mentioned in this
thread before, part of the problem is module signing is not an LSM. Now with
LSM stacking in place it should in theory be possible to LSM'ify module signing,
but that requires work, module signing would then become a mini LSM and distros
can stack it.

  Luis

Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi

[Andy Lutomirski]

On a related topic: last year or so, I argued that
CONFIG_MODULE_SIG_ALL and, more generally, the idea that in-tree
modules should be signed, is a suboptimal design.  Instead, I think
that the kernel shoud just learn to recognize its in-tree modules by
hash.  This would allow reproducible builds, get rid of the
autogenerated key, and would allow distros that don't support binary
modules to avoid needing the asymmetric key infrastructure at all (for
modules, anyway -- firmware is a different story.  But a firmware
signing key doesn't interfere with the kernel build process the way
that an in-tree module signing key does.)

On the theory that code speaks louder than vitriol, I decided to try
to implement it.  The actual code is trivial (I expect under 50 lines
*total* for the compile-time and run-time parts together), but
convincing make to build the thing is a real pain in the arse.

So expect code from me before KS unless I really get stuck fighting
kbuild.  And, unless anyone objects, I intend to propose that we
delete CONFIG_MODULE_SIG_ALL entirely once this thing works.

--Andy

Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi

[Ard Biesheuvel]

On 2 August 2016 at 20:55, Andy Lutomirski <luto@amacapital.net> wrote:
> On a related topic: last year or so, I argued that
> CONFIG_MODULE_SIG_ALL and, more generally, the idea that in-tree
> modules should be signed, is a suboptimal design.  Instead, I think
> that the kernel shoud just learn to recognize its in-tree modules by
> hash.  This would allow reproducible builds, get rid of the
> autogenerated key, and would allow distros that don't support binary
> modules to avoid needing the asymmetric key infrastructure at all (for
> modules, anyway -- firmware is a different story.  But a firmware
> signing key doesn't interfere with the kernel build process the way
> that an in-tree module signing key does.)
>
> On the theory that code speaks louder than vitriol, I decided to try
> to implement it.  The actual code is trivial (I expect under 50 lines
> *total* for the compile-time and run-time parts together), but
> convincing make to build the thing is a real pain in the arse.
>
> So expect code from me before KS unless I really get stuck fighting
> kbuild.  And, unless anyone objects, I intend to propose that we
> delete CONFIG_MODULE_SIG_ALL entirely once this thing works.
>

This is exactly what I implemented for TomTom years ago, and the only
issues I remember from the top of my head were:
- build order: vmlinux needs to be built after the modules, but
currently, building the modules requires vmlinux to be built already
- debug symbols: modules are stripped when installing them, and taking
the hash needs to be done afterwards

Then,c-ize a build time sorted list of hashes, and do a binary search
at verification time.

Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi

[Andy Lutomirski]

On Tue, Aug 2, 2016 at 12:02 PM, Ard Biesheuvel
<ard.biesheuvel@linaro.org> wrote:
> On 2 August 2016 at 20:55, Andy Lutomirski <luto@amacapital.net> wrote:
>> On a related topic: last year or so, I argued that
>> CONFIG_MODULE_SIG_ALL and, more generally, the idea that in-tree
>> modules should be signed, is a suboptimal design.  Instead, I think
>> that the kernel shoud just learn to recognize its in-tree modules by
>> hash.  This would allow reproducible builds, get rid of the
>> autogenerated key, and would allow distros that don't support binary
>> modules to avoid needing the asymmetric key infrastructure at all (for
>> modules, anyway -- firmware is a different story.  But a firmware
>> signing key doesn't interfere with the kernel build process the way
>> that an in-tree module signing key does.)
>>
>> On the theory that code speaks louder than vitriol, I decided to try
>> to implement it.  The actual code is trivial (I expect under 50 lines
>> *total* for the compile-time and run-time parts together), but
>> convincing make to build the thing is a real pain in the arse.
>>
>> So expect code from me before KS unless I really get stuck fighting
>> kbuild.  And, unless anyone objects, I intend to propose that we
>> delete CONFIG_MODULE_SIG_ALL entirely once this thing works.
>>
>
> This is exactly what I implemented for TomTom years ago, and the only
> issues I remember from the top of my head were:
> - build order: vmlinux needs to be built after the modules, but
> currently, building the modules requires vmlinux to be built already

I am, literally right now, fighting kbuild to make this happen.  I
think I got it mostly working.

> - debug symbols: modules are stripped when installing them, and taking
> the hash needs to be done afterwards

I don't know whether this is cleanly fixable directly.  We could add a
way for distros to hook the build process so that they can insert the
strip operation in the right place.  We could also have
CONFIG_STRIP_MODULES that automatically splits the debug info out from
the modules.

>
> Then,c-ize a build time sorted list of hashes, and do a binary search
> at verification time.

Would you believe I'm implementing exactly that algorithm? :)

--Andy

Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi

[Ard Biesheuvel]

On 2 August 2016 at 21:08, Andy Lutomirski <luto@amacapital.net> wrote:
> On Tue, Aug 2, 2016 at 12:02 PM, Ard Biesheuvel
> <ard.biesheuvel@linaro.org> wrote:
>> On 2 August 2016 at 20:55, Andy Lutomirski <luto@amacapital.net> wrote:
>>> On a related topic: last year or so, I argued that
>>> CONFIG_MODULE_SIG_ALL and, more generally, the idea that in-tree
>>> modules should be signed, is a suboptimal design.  Instead, I think
>>> that the kernel shoud just learn to recognize its in-tree modules by
>>> hash.  This would allow reproducible builds, get rid of the
>>> autogenerated key, and would allow distros that don't support binary
>>> modules to avoid needing the asymmetric key infrastructure at all (for
>>> modules, anyway -- firmware is a different story.  But a firmware
>>> signing key doesn't interfere with the kernel build process the way
>>> that an in-tree module signing key does.)
>>>
>>> On the theory that code speaks louder than vitriol, I decided to try
>>> to implement it.  The actual code is trivial (I expect under 50 lines
>>> *total* for the compile-time and run-time parts together), but
>>> convincing make to build the thing is a real pain in the arse.
>>>
>>> So expect code from me before KS unless I really get stuck fighting
>>> kbuild.  And, unless anyone objects, I intend to propose that we
>>> delete CONFIG_MODULE_SIG_ALL entirely once this thing works.
>>>
>>
>> This is exactly what I implemented for TomTom years ago, and the only
>> issues I remember from the top of my head were:
>> - build order: vmlinux needs to be built after the modules, but
>> currently, building the modules requires vmlinux to be built already
>
> I am, literally right now, fighting kbuild to make this happen.  I
> think I got it mostly working.
>
>> - debug symbols: modules are stripped when installing them, and taking
>> the hash needs to be done afterwards
>
> I don't know whether this is cleanly fixable directly.  We could add a
> way for distros to hook the build process so that they can insert the
> strip operation in the right place.  We could also have
> CONFIG_STRIP_MODULES that automatically splits the debug info out from
> the modules.
>
>>
>> Then,c-ize a build time sorted list of hashes, and do a binary search
>> at verification time.
>
> Would you believe I'm implementing exactly that algorithm? :)
>

Been there, done that :-)

Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi

[Andy Lutomirski]

[-- Attachment #1: Type: text/plain, Size: 2631 bytes --]

On Aug 2, 2016 12:14 PM, "Ard Biesheuvel" <ard.biesheuvel@linaro.org> wrote:
>
> On 2 August 2016 at 21:08, Andy Lutomirski <luto@amacapital.net> wrote:
> > On Tue, Aug 2, 2016 at 12:02 PM, Ard Biesheuvel
> > <ard.biesheuvel@linaro.org> wrote:
> >> On 2 August 2016 at 20:55, Andy Lutomirski <luto@amacapital.net> wrote:
> >>> On a related topic: last year or so, I argued that
> >>> CONFIG_MODULE_SIG_ALL and, more generally, the idea that in-tree
> >>> modules should be signed, is a suboptimal design.  Instead, I think
> >>> that the kernel shoud just learn to recognize its in-tree modules by
> >>> hash.  This would allow reproducible builds, get rid of the
> >>> autogenerated key, and would allow distros that don't support binary
> >>> modules to avoid needing the asymmetric key infrastructure at all (for
> >>> modules, anyway -- firmware is a different story.  But a firmware
> >>> signing key doesn't interfere with the kernel build process the way
> >>> that an in-tree module signing key does.)
> >>>
> >>> On the theory that code speaks louder than vitriol, I decided to try
> >>> to implement it.  The actual code is trivial (I expect under 50 lines
> >>> *total* for the compile-time and run-time parts together), but
> >>> convincing make to build the thing is a real pain in the arse.
> >>>
> >>> So expect code from me before KS unless I really get stuck fighting
> >>> kbuild.  And, unless anyone objects, I intend to propose that we
> >>> delete CONFIG_MODULE_SIG_ALL entirely once this thing works.
> >>>
> >>
> >> This is exactly what I implemented for TomTom years ago, and the only
> >> issues I remember from the top of my head were:
> >> - build order: vmlinux needs to be built after the modules, but
> >> currently, building the modules requires vmlinux to be built already
> >
> > I am, literally right now, fighting kbuild to make this happen.  I
> > think I got it mostly working.
> >
> >> - debug symbols: modules are stripped when installing them, and taking
> >> the hash needs to be done afterwards
> >
> > I don't know whether this is cleanly fixable directly.  We could add a
> > way for distros to hook the build process so that they can insert the
> > strip operation in the right place.  We could also have
> > CONFIG_STRIP_MODULES that automatically splits the debug info out from
> > the modules.
> >
> >>
> >> Then,c-ize a build time sorted list of hashes, and do a binary search
> >> at verification time.
> >
> > Would you believe I'm implementing exactly that algorithm? :)
> >
>
> Been there, done that :-)

Do you have code you can share?  I'm always in favor of doing less work!

[-- Attachment #2: Type: text/html, Size: 3626 bytes --]

Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi

[Ard Biesheuvel]

On 2 August 2016 at 21:17, Andy Lutomirski <luto@amacapital.net> wrote:
> On Aug 2, 2016 12:14 PM, "Ard Biesheuvel" <ard.biesheuvel@linaro.org> wrote:
>>
>> On 2 August 2016 at 21:08, Andy Lutomirski <luto@amacapital.net> wrote:
>> > On Tue, Aug 2, 2016 at 12:02 PM, Ard Biesheuvel
>> > <ard.biesheuvel@linaro.org> wrote:
>> >> On 2 August 2016 at 20:55, Andy Lutomirski <luto@amacapital.net> wrote:
>> >>> On a related topic: last year or so, I argued that
>> >>> CONFIG_MODULE_SIG_ALL and, more generally, the idea that in-tree
>> >>> modules should be signed, is a suboptimal design.  Instead, I think
>> >>> that the kernel shoud just learn to recognize its in-tree modules by
>> >>> hash.  This would allow reproducible builds, get rid of the
>> >>> autogenerated key, and would allow distros that don't support binary
>> >>> modules to avoid needing the asymmetric key infrastructure at all (for
>> >>> modules, anyway -- firmware is a different story.  But a firmware
>> >>> signing key doesn't interfere with the kernel build process the way
>> >>> that an in-tree module signing key does.)
>> >>>
>> >>> On the theory that code speaks louder than vitriol, I decided to try
>> >>> to implement it.  The actual code is trivial (I expect under 50 lines
>> >>> *total* for the compile-time and run-time parts together), but
>> >>> convincing make to build the thing is a real pain in the arse.
>> >>>
>> >>> So expect code from me before KS unless I really get stuck fighting
>> >>> kbuild.  And, unless anyone objects, I intend to propose that we
>> >>> delete CONFIG_MODULE_SIG_ALL entirely once this thing works.
>> >>>
>> >>
>> >> This is exactly what I implemented for TomTom years ago, and the only
>> >> issues I remember from the top of my head were:
>> >> - build order: vmlinux needs to be built after the modules, but
>> >> currently, building the modules requires vmlinux to be built already
>> >
>> > I am, literally right now, fighting kbuild to make this happen.  I
>> > think I got it mostly working.
>> >
>> >> - debug symbols: modules are stripped when installing them, and taking
>> >> the hash needs to be done afterwards
>> >
>> > I don't know whether this is cleanly fixable directly.  We could add a
>> > way for distros to hook the build process so that they can insert the
>> > strip operation in the right place.  We could also have
>> > CONFIG_STRIP_MODULES that automatically splits the debug info out from
>> > the modules.
>> >
>> >>
>> >> Then,c-ize a build time sorted list of hashes, and do a binary search
>> >> at verification time.
>> >
>> > Would you believe I'm implementing exactly that algorithm? :)
>> >
>>
>> Been there, done that :-)
>
> Do you have code you can share?  I'm always in favor of doing less work!

It should be in here somewhere
http://www.tomtom.com/gpl/arm11/linux-kernel-2.6.28-tt855479.tar.gz

I'm currently on a crappy connection, and I don't have access anymore
to the git repo, unfortunately.
I can dig it up tomorrow if you don't beat me to it

Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi

[Ard Biesheuvel]

On 2 August 2016 at 21:20, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> On 2 August 2016 at 21:17, Andy Lutomirski <luto@amacapital.net> wrote:
>> On Aug 2, 2016 12:14 PM, "Ard Biesheuvel" <ard.biesheuvel@linaro.org> wrote:
>>>
>>> On 2 August 2016 at 21:08, Andy Lutomirski <luto@amacapital.net> wrote:
>>> > On Tue, Aug 2, 2016 at 12:02 PM, Ard Biesheuvel
>>> > <ard.biesheuvel@linaro.org> wrote:
>>> >> On 2 August 2016 at 20:55, Andy Lutomirski <luto@amacapital.net> wrote:
>>> >>> On a related topic: last year or so, I argued that
>>> >>> CONFIG_MODULE_SIG_ALL and, more generally, the idea that in-tree
>>> >>> modules should be signed, is a suboptimal design.  Instead, I think
>>> >>> that the kernel shoud just learn to recognize its in-tree modules by
>>> >>> hash.  This would allow reproducible builds, get rid of the
>>> >>> autogenerated key, and would allow distros that don't support binary
>>> >>> modules to avoid needing the asymmetric key infrastructure at all (for
>>> >>> modules, anyway -- firmware is a different story.  But a firmware
>>> >>> signing key doesn't interfere with the kernel build process the way
>>> >>> that an in-tree module signing key does.)
>>> >>>
>>> >>> On the theory that code speaks louder than vitriol, I decided to try
>>> >>> to implement it.  The actual code is trivial (I expect under 50 lines
>>> >>> *total* for the compile-time and run-time parts together), but
>>> >>> convincing make to build the thing is a real pain in the arse.
>>> >>>
>>> >>> So expect code from me before KS unless I really get stuck fighting
>>> >>> kbuild.  And, unless anyone objects, I intend to propose that we
>>> >>> delete CONFIG_MODULE_SIG_ALL entirely once this thing works.
>>> >>>
>>> >>
>>> >> This is exactly what I implemented for TomTom years ago, and the only
>>> >> issues I remember from the top of my head were:
>>> >> - build order: vmlinux needs to be built after the modules, but
>>> >> currently, building the modules requires vmlinux to be built already
>>> >
>>> > I am, literally right now, fighting kbuild to make this happen.  I
>>> > think I got it mostly working.
>>> >
>>> >> - debug symbols: modules are stripped when installing them, and taking
>>> >> the hash needs to be done afterwards
>>> >
>>> > I don't know whether this is cleanly fixable directly.  We could add a
>>> > way for distros to hook the build process so that they can insert the
>>> > strip operation in the right place.  We could also have
>>> > CONFIG_STRIP_MODULES that automatically splits the debug info out from
>>> > the modules.
>>> >
>>> >>
>>> >> Then,c-ize a build time sorted list of hashes, and do a binary search
>>> >> at verification time.
>>> >
>>> > Would you believe I'm implementing exactly that algorithm? :)
>>> >
>>>
>>> Been there, done that :-)
>>
>> Do you have code you can share?  I'm always in favor of doing less work!
>
> It should be in here somewhere
> http://www.tomtom.com/gpl/arm11/linux-kernel-2.6.28-tt855479.tar.gz
>
> I'm currently on a crappy connection, and I don't have access anymore
> to the git repo, unfortunately.
> I can dig it up tomorrow if you don't beat me to it

Actually, I did find a patch against some 2.6.x kernel that contains
the module hashing, plus some other security stuff I did for tomtom.

Look for CONFIG_MODULE_HASHES in

http://people.linaro.org/~ard.biesheuvel/irvine.diff

-- 
Ard.

Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi

[Ben Hutchings]

[-- Attachment #1: Type: text/plain, Size: 3232 bytes --]

On Wed, 2016-07-27 at 12:36 -0400, James Bottomley wrote:
> On Wed, 2016-07-27 at 12:28 -0400, James Bottomley wrote:
> > On Wed, 2016-07-27 at 17:14 +0100, David Howells wrote:
> > > James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
> > > 
> > > >    1. Population and update policy: How should we populate the default
> > > >       keyrings and revocation lists?  Should we have a built in list of
> > > >       absolute trust that can never be added to? I think the current
> > > >       default here is OK: it's populate with the kernel built in keys and
> > > >       nothing else.  If userspace wants to populate with, say, the secure
> > > >       boot keys, then it can do so from init.  An issue here is the
> > > >       Microsoft signing key, which most Linux people have but which they
> > > >       wouldn't necessarily consider to be a source of absolute trust. 
> > > >        However, third party driver vendors would like a way to get their
> > > >       key trusted by the kernel so they can easily supply modules (This
> > > >       isn't a binary module issue: the code is usually GPL, but the
> > > >       vendors would like to supply updates asynchronously to the distro
> > > >       release cycle).  We can say their key should be added as part of the
> > > >       rpm that installs the module, but do users really want this key
> > > >       adding to the default keyring to be trusted for non-module
> > > >       operations?
> > > 
> > > I have patches that allow the UEFI key and blacklist databases to 
> > > add to the kernel keyrings during boot.
> > > 
> > > We don't want to permit loading a key from a file once the kernel 
> > > is booted unless that key is signed by a key already in the
> > > keyrings.
> > 
> > This is a policy discussion we should have.  If you populate the
> > immutable .builtin_trusted_keys keyring with the secure boot keys, 
> > most people will end up with a Microsoft key in their keyring (and
> > possibly even some random motherboard vendor ODM key) which they 
> > can't remove.  I thought the idea was to use the 
> > .secondary_trusted_keys keyring which is mutable?  That way we can 
> > have policy in userspace select which secure boot keys we might like
> > to trust.
> 
> As an aside to the aside, perhaps we want the .builtin_trusted_keys to
> be mutable up to the point the kernel finishes init and then immutable
> after.  That would allow us to update it from the initrd if the
> composition of the secure boot keys was in question.

That would seem to open a large hole unless the initramfs can be
verified as trusted (either by the boot loader or the kernel).

Speaking of holes in code signing, the securelevel patches never went
into mainline.  Is it worth discussing again how/whether to implement
that sort of restrictions?

Ben.

-- 

Ben Hutchings
Experience is directly proportional to the value of equipment
destroyed.
                                                         - Carolyn
Scheppner

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi

[Mimi Zohar]

On Fr, 2016-07-29 at 13:43 +0100, Ben Hutchings wrote:
> On Wed, 2016-07-27 at 12:36 -0400, James Bottomley wrote:
> > On Wed, 2016-07-27 at 12:28 -0400, James Bottomley wrote:

> 
> That would seem to open a large hole unless the initramfs can be
> verified as trusted (either by the boot loader or the kernel).

Commit b804def "kexec: replace call to copy_file_from_fd() with kernel
version"  adds support for measuring and verifying the kernel image and
initramfs signatures.

The next step would be to measure and verify file signatures within the
initramfs.  That work was started, but has not been upstreamed yet.

Mimi