* [Ksummit-discuss] Last minute nominations: mcgrof and toshi @ 2015-08-04 15:26 Luis R. Rodriguez 2015-08-04 22:20 ` Toshi Kani 2016-07-15 19:50 ` Mimi Zohar 0 siblings, 2 replies; 101+ messages in thread From: Luis R. Rodriguez @ 2015-08-04 15:26 UTC (permalink / raw) To: ksummit-discuss 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 ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi 2015-08-04 15:26 [Ksummit-discuss] Last minute nominations: mcgrof and toshi Luis R. Rodriguez @ 2015-08-04 22:20 ` Toshi Kani 2016-07-15 19:50 ` Mimi Zohar 1 sibling, 0 replies; 101+ messages in thread From: Toshi Kani @ 2015-08-04 22:20 UTC (permalink / raw) To: Luis R. Rodriguez, ksummit-discuss 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 ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi 2015-08-04 15:26 [Ksummit-discuss] Last minute nominations: mcgrof and toshi Luis R. Rodriguez 2015-08-04 22:20 ` Toshi Kani @ 2016-07-15 19:50 ` Mimi Zohar 2016-07-15 19:57 ` Mimi Zohar 1 sibling, 1 reply; 101+ messages in thread From: Mimi Zohar @ 2016-07-15 19:50 UTC (permalink / raw) To: Luis R. Rodriguez; +Cc: ksummit-discuss 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 ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi 2016-07-15 19:50 ` Mimi Zohar @ 2016-07-15 19:57 ` Mimi Zohar 2016-07-16 0:52 ` Mark Brown 0 siblings, 1 reply; 101+ messages in thread From: Mimi Zohar @ 2016-07-15 19:57 UTC (permalink / raw) To: Luis R. Rodriguez; +Cc: ksummit-discuss Oops, "Signature management - keys, modules, firmware" was a suggestion from last year, but in my opinion still very apropos. Mimi ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi 2016-07-15 19:57 ` Mimi Zohar @ 2016-07-16 0:52 ` Mark Brown 2016-07-26 14:42 ` David Woodhouse 0 siblings, 1 reply; 101+ messages in thread From: Mark Brown @ 2016-07-16 0:52 UTC (permalink / raw) To: Mimi Zohar; +Cc: ksummit-discuss [-- 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 --] ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi 2016-07-16 0:52 ` Mark Brown @ 2016-07-26 14:42 ` David Woodhouse 2016-07-27 14:04 ` [Ksummit-discuss] [TECH TOPIC] Signature management - keys, modules, firmware, was: " Jason Cooper ` (6 more replies) 0 siblings, 7 replies; 101+ messages in thread From: David Woodhouse @ 2016-07-26 14:42 UTC (permalink / raw) To: Mark Brown, Mimi Zohar, dhowells; +Cc: ksummit-discuss [-- 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 --] ^ permalink raw reply [flat|nested] 101+ messages in thread
* [Ksummit-discuss] [TECH TOPIC] Signature management - keys, modules, firmware, was: Last minute nominations: mcgrof and toshi 2016-07-26 14:42 ` David Woodhouse @ 2016-07-27 14:04 ` Jason Cooper 2016-07-27 14:58 ` Mark Rutland ` (3 more replies) 2016-07-27 14:08 ` David Howells ` (5 subsequent siblings) 6 siblings, 4 replies; 101+ messages in thread From: Jason Cooper @ 2016-07-27 14:04 UTC (permalink / raw) To: David Woodhouse; +Cc: Mark Brown, ksummit-discuss 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. ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [Ksummit-discuss] [TECH TOPIC] Signature management - keys, modules, firmware, was: Last minute nominations: mcgrof and toshi 2016-07-27 14:04 ` [Ksummit-discuss] [TECH TOPIC] Signature management - keys, modules, firmware, was: " Jason Cooper @ 2016-07-27 14:58 ` Mark Rutland 2016-07-27 18:17 ` Stephen Hemminger ` (2 subsequent siblings) 3 siblings, 0 replies; 101+ messages in thread From: Mark Rutland @ 2016-07-27 14:58 UTC (permalink / raw) To: Jason Cooper; +Cc: Mark Brown, ksummit-discuss 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. ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [Ksummit-discuss] [TECH TOPIC] Signature management - keys, modules, firmware, was: Last minute nominations: mcgrof and toshi 2016-07-27 14:04 ` [Ksummit-discuss] [TECH TOPIC] Signature management - keys, modules, firmware, was: " Jason Cooper 2016-07-27 14:58 ` Mark Rutland @ 2016-07-27 18:17 ` Stephen Hemminger 2016-07-27 18:36 ` Andy Lutomirski 2016-07-29 12:29 ` Ben Hutchings 2016-08-02 12:54 ` Linus Walleij 3 siblings, 1 reply; 101+ messages in thread From: Stephen Hemminger @ 2016-07-27 18:17 UTC (permalink / raw) To: Jason Cooper; +Cc: Mark Brown, ksummit-discuss 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. ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [Ksummit-discuss] [TECH TOPIC] Signature management - keys, modules, firmware, was: Last minute nominations: mcgrof and toshi 2016-07-27 18:17 ` Stephen Hemminger @ 2016-07-27 18:36 ` Andy Lutomirski 0 siblings, 0 replies; 101+ messages in thread From: Andy Lutomirski @ 2016-07-27 18:36 UTC (permalink / raw) To: Stephen Hemminger; +Cc: Mark Brown, ksummit-discuss, Jason Cooper [-- 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 --] ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [Ksummit-discuss] [TECH TOPIC] Signature management - keys, modules, firmware, was: Last minute nominations: mcgrof and toshi 2016-07-27 14:04 ` [Ksummit-discuss] [TECH TOPIC] Signature management - keys, modules, firmware, was: " Jason Cooper 2016-07-27 14:58 ` Mark Rutland 2016-07-27 18:17 ` Stephen Hemminger @ 2016-07-29 12:29 ` Ben Hutchings 2016-08-05 17:16 ` Mimi Zohar 2016-08-02 12:54 ` Linus Walleij 3 siblings, 1 reply; 101+ messages in thread From: Ben Hutchings @ 2016-07-29 12:29 UTC (permalink / raw) To: Jason Cooper, David Woodhouse; +Cc: Mark Brown, ksummit-discuss [-- 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 --] ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [Ksummit-discuss] [TECH TOPIC] Signature management - keys, modules, firmware, was: Last minute nominations: mcgrof and toshi 2016-07-29 12:29 ` Ben Hutchings @ 2016-08-05 17:16 ` Mimi Zohar 2016-08-05 18:24 ` Ben Hutchings 0 siblings, 1 reply; 101+ messages in thread From: Mimi Zohar @ 2016-08-05 17:16 UTC (permalink / raw) To: Ben Hutchings; +Cc: Jason Cooper, ksummit-discuss, Mark Brown 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 ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [Ksummit-discuss] [TECH TOPIC] Signature management - keys, modules, firmware, was: Last minute nominations: mcgrof and toshi 2016-08-05 17:16 ` Mimi Zohar @ 2016-08-05 18:24 ` Ben Hutchings 0 siblings, 0 replies; 101+ messages in thread From: Ben Hutchings @ 2016-08-05 18:24 UTC (permalink / raw) To: Mimi Zohar; +Cc: Jason Cooper, ksummit-discuss, Mark Brown [-- 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 --] ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [Ksummit-discuss] [TECH TOPIC] Signature management - keys, modules, firmware, was: Last minute nominations: mcgrof and toshi 2016-07-27 14:04 ` [Ksummit-discuss] [TECH TOPIC] Signature management - keys, modules, firmware, was: " Jason Cooper ` (2 preceding siblings ...) 2016-07-29 12:29 ` Ben Hutchings @ 2016-08-02 12:54 ` Linus Walleij 2016-08-02 14:00 ` Jason Cooper 2016-08-02 14:13 ` James Bottomley 3 siblings, 2 replies; 101+ messages in thread From: Linus Walleij @ 2016-08-02 12:54 UTC (permalink / raw) To: Jason Cooper; +Cc: Mark Brown, ksummit-discuss 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 ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [Ksummit-discuss] [TECH TOPIC] Signature management - keys, modules, firmware, was: Last minute nominations: mcgrof and toshi 2016-08-02 12:54 ` Linus Walleij @ 2016-08-02 14:00 ` Jason Cooper 2016-08-02 14:09 ` David Woodhouse [not found] ` <CALCETrUjn7TeGbS4TQ+OFih-nby2Rh54i5177MOwqjTYDBMO=A@mail.gmail.com> 2016-08-02 14:13 ` James Bottomley 1 sibling, 2 replies; 101+ messages in thread From: Jason Cooper @ 2016-08-02 14:00 UTC (permalink / raw) To: Linus Walleij; +Cc: Mark Brown, ksummit-discuss 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. ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [Ksummit-discuss] [TECH TOPIC] Signature management - keys, modules, firmware, was: Last minute nominations: mcgrof and toshi 2016-08-02 14:00 ` Jason Cooper @ 2016-08-02 14:09 ` David Woodhouse [not found] ` <CALCETrUjn7TeGbS4TQ+OFih-nby2Rh54i5177MOwqjTYDBMO=A@mail.gmail.com> 1 sibling, 0 replies; 101+ messages in thread From: David Woodhouse @ 2016-08-02 14:09 UTC (permalink / raw) To: Jason Cooper, Linus Walleij; +Cc: Mark Brown, ksummit-discuss [-- 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 --] ^ permalink raw reply [flat|nested] 101+ messages in thread
[parent not found: <CALCETrUjn7TeGbS4TQ+OFih-nby2Rh54i5177MOwqjTYDBMO=A@mail.gmail.com>]
[parent not found: <CALCETrU6aQ5PR_+M7QHkTWos6i6vVS2nvEQDwr5ktBkWu-5MKw@mail.gmail.com>]
[parent not found: <CALCETrW8uRK4cuQ+B6NPcO0pY-=-HRDf4LZk4xv2QdPzNEvMCg@mail.gmail.com>]
[parent not found: <CALCETrW_mQLmR6g_Ar8Nnpr7CRFZhth=Hj9C901Gj7_WSp=yEQ@mail.gmail.com>]
* Re: [Ksummit-discuss] [TECH TOPIC] Signature management - keys, modules, firmware, was: Last minute nominations: mcgrof and toshi [not found] ` <CALCETrW_mQLmR6g_Ar8Nnpr7CRFZhth=Hj9C901Gj7_WSp=yEQ@mail.gmail.com> @ 2016-08-02 14:53 ` Andy Lutomirski 0 siblings, 0 replies; 101+ messages in thread From: Andy Lutomirski @ 2016-08-02 14:53 UTC (permalink / raw) To: Jason Cooper; +Cc: Mark Brown, ksummit-discuss [-- 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 --] ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [Ksummit-discuss] [TECH TOPIC] Signature management - keys, modules, firmware, was: Last minute nominations: mcgrof and toshi 2016-08-02 12:54 ` Linus Walleij 2016-08-02 14:00 ` Jason Cooper @ 2016-08-02 14:13 ` James Bottomley 2016-08-03 9:47 ` Linus Walleij 1 sibling, 1 reply; 101+ messages in thread From: James Bottomley @ 2016-08-02 14:13 UTC (permalink / raw) To: Linus Walleij, Jason Cooper; +Cc: Mark Brown, ksummit-discuss 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 ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [Ksummit-discuss] [TECH TOPIC] Signature management - keys, modules, firmware, was: Last minute nominations: mcgrof and toshi 2016-08-02 14:13 ` James Bottomley @ 2016-08-03 9:47 ` Linus Walleij 2016-08-03 10:00 ` Jiri Kosina ` (2 more replies) 0 siblings, 3 replies; 101+ messages in thread From: Linus Walleij @ 2016-08-03 9:47 UTC (permalink / raw) To: James Bottomley; +Cc: Jason Cooper, ksummit-discuss, Mark Brown 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 ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [Ksummit-discuss] [TECH TOPIC] Signature management - keys, modules, firmware, was: Last minute nominations: mcgrof and toshi 2016-08-03 9:47 ` Linus Walleij @ 2016-08-03 10:00 ` Jiri Kosina 2016-08-03 10:28 ` Jani Nikula 2016-08-12 12:38 ` Vinod Koul 2 siblings, 0 replies; 101+ messages in thread From: Jiri Kosina @ 2016-08-03 10:00 UTC (permalink / raw) To: Linus Walleij; +Cc: James Bottomley, Jason Cooper, ksummit-discuss, Mark Brown 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 ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [Ksummit-discuss] [TECH TOPIC] Signature management - keys, modules, firmware, was: Last minute nominations: mcgrof and toshi 2016-08-03 9:47 ` Linus Walleij 2016-08-03 10:00 ` Jiri Kosina @ 2016-08-03 10:28 ` Jani Nikula 2016-08-03 10:41 ` Linus Walleij 2016-08-12 12:38 ` Vinod Koul 2 siblings, 1 reply; 101+ messages in thread From: Jani Nikula @ 2016-08-03 10:28 UTC (permalink / raw) To: Linus Walleij, James Bottomley; +Cc: Jason Cooper, ksummit-discuss, Mark Brown 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 ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [Ksummit-discuss] [TECH TOPIC] Signature management - keys, modules, firmware, was: Last minute nominations: mcgrof and toshi 2016-08-03 10:28 ` Jani Nikula @ 2016-08-03 10:41 ` Linus Walleij 2016-08-03 11:18 ` Jani Nikula 2016-08-03 15:19 ` Jason Cooper 0 siblings, 2 replies; 101+ messages in thread From: Linus Walleij @ 2016-08-03 10:41 UTC (permalink / raw) To: Jani Nikula; +Cc: James Bottomley, Jason Cooper, ksummit-discuss, Mark Brown 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 ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [Ksummit-discuss] [TECH TOPIC] Signature management - keys, modules, firmware, was: Last minute nominations: mcgrof and toshi 2016-08-03 10:41 ` Linus Walleij @ 2016-08-03 11:18 ` Jani Nikula 2016-08-03 15:19 ` Jason Cooper 1 sibling, 0 replies; 101+ messages in thread From: Jani Nikula @ 2016-08-03 11:18 UTC (permalink / raw) To: Linus Walleij; +Cc: James Bottomley, Jason Cooper, ksummit-discuss, Mark Brown 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 ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [Ksummit-discuss] [TECH TOPIC] Signature management - keys, modules, firmware, was: Last minute nominations: mcgrof and toshi 2016-08-03 10:41 ` Linus Walleij 2016-08-03 11:18 ` Jani Nikula @ 2016-08-03 15:19 ` Jason Cooper 1 sibling, 0 replies; 101+ messages in thread From: Jason Cooper @ 2016-08-03 15:19 UTC (permalink / raw) To: Linus Walleij; +Cc: James Bottomley, Mark Brown, ksummit-discuss 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. ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [Ksummit-discuss] [TECH TOPIC] Signature management - keys, modules, firmware, was: Last minute nominations: mcgrof and toshi 2016-08-03 9:47 ` Linus Walleij 2016-08-03 10:00 ` Jiri Kosina 2016-08-03 10:28 ` Jani Nikula @ 2016-08-12 12:38 ` Vinod Koul 2016-08-12 12:39 ` David Woodhouse 2016-08-12 12:54 ` Andy Lutomirski 2 siblings, 2 replies; 101+ messages in thread From: Vinod Koul @ 2016-08-12 12:38 UTC (permalink / raw) To: Linus Walleij; +Cc: James Bottomley, Jason Cooper, ksummit-discuss, Mark Brown 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 ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [Ksummit-discuss] [TECH TOPIC] Signature management - keys, modules, firmware, was: Last minute nominations: mcgrof and toshi 2016-08-12 12:38 ` Vinod Koul @ 2016-08-12 12:39 ` David Woodhouse 2016-08-12 12:54 ` Andy Lutomirski 1 sibling, 0 replies; 101+ messages in thread From: David Woodhouse @ 2016-08-12 12:39 UTC (permalink / raw) To: Vinod Koul, Linus Walleij Cc: James Bottomley, Jason Cooper, ksummit-discuss, Mark Brown [-- 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 --] ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [Ksummit-discuss] [TECH TOPIC] Signature management - keys, modules, firmware, was: Last minute nominations: mcgrof and toshi 2016-08-12 12:38 ` Vinod Koul 2016-08-12 12:39 ` David Woodhouse @ 2016-08-12 12:54 ` Andy Lutomirski 2016-08-12 13:00 ` David Woodhouse 2016-08-12 13:12 ` Vinod Koul 1 sibling, 2 replies; 101+ messages in thread From: Andy Lutomirski @ 2016-08-12 12:54 UTC (permalink / raw) To: Vinod Koul; +Cc: James Bottomley, Mark Brown, ksummit-discuss, Jason Cooper [-- 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 --] ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [Ksummit-discuss] [TECH TOPIC] Signature management - keys, modules, firmware, was: Last minute nominations: mcgrof and toshi 2016-08-12 12:54 ` Andy Lutomirski @ 2016-08-12 13:00 ` David Woodhouse 2016-08-12 13:12 ` Vinod Koul 1 sibling, 0 replies; 101+ messages in thread From: David Woodhouse @ 2016-08-12 13:00 UTC (permalink / raw) To: Andy Lutomirski, Vinod Koul Cc: James Bottomley, Mark Brown, ksummit-discuss, Jason Cooper [-- 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 --] ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [Ksummit-discuss] [TECH TOPIC] Signature management - keys, modules, firmware, was: Last minute nominations: mcgrof and toshi 2016-08-12 12:54 ` Andy Lutomirski 2016-08-12 13:00 ` David Woodhouse @ 2016-08-12 13:12 ` Vinod Koul 1 sibling, 0 replies; 101+ messages in thread From: Vinod Koul @ 2016-08-12 13:12 UTC (permalink / raw) To: Andy Lutomirski Cc: James Bottomley, Mark Brown, ksummit-discuss, Jason Cooper 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 ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [Ksummit-discuss] [TECH TOPIC] Signature management - keys, modules, firmware, was: Last minute nominations: mcgrof and toshi 2016-07-26 14:42 ` David Woodhouse 2016-07-27 14:04 ` [Ksummit-discuss] [TECH TOPIC] Signature management - keys, modules, firmware, was: " Jason Cooper @ 2016-07-27 14:08 ` David Howells 2016-07-27 14:10 ` Ard Biesheuvel 2016-07-27 15:06 ` [Ksummit-discuss] " James Bottomley ` (4 subsequent siblings) 6 siblings, 1 reply; 101+ messages in thread From: David Howells @ 2016-07-27 14:08 UTC (permalink / raw) To: Jason Cooper; +Cc: Mark Brown, ksummit-discuss I would want to attend this. David ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [Ksummit-discuss] [TECH TOPIC] Signature management - keys, modules, firmware, was: Last minute nominations: mcgrof and toshi 2016-07-27 14:08 ` David Howells @ 2016-07-27 14:10 ` Ard Biesheuvel 2016-07-27 14:23 ` Mark Brown 0 siblings, 1 reply; 101+ messages in thread From: Ard Biesheuvel @ 2016-07-27 14:10 UTC (permalink / raw) To: David Howells; +Cc: Jason Cooper, ksummit-discuss, Mark Brown On 27 July 2016 at 16:08, David Howells <dhowells@redhat.com> wrote: > I would want to attend this. > So would I -- Ard. ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [Ksummit-discuss] [TECH TOPIC] Signature management - keys, modules, firmware, was: Last minute nominations: mcgrof and toshi 2016-07-27 14:10 ` Ard Biesheuvel @ 2016-07-27 14:23 ` Mark Brown 0 siblings, 0 replies; 101+ messages in thread From: Mark Brown @ 2016-07-27 14:23 UTC (permalink / raw) To: Ard Biesheuvel; +Cc: Jason Cooper, ksummit-discuss [-- 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 --] ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi 2016-07-26 14:42 ` David Woodhouse 2016-07-27 14:04 ` [Ksummit-discuss] [TECH TOPIC] Signature management - keys, modules, firmware, was: " Jason Cooper 2016-07-27 14:08 ` David Howells @ 2016-07-27 15:06 ` James Bottomley 2016-08-01 10:22 ` Johannes Berg 2016-07-27 15:37 ` David Howells ` (3 subsequent siblings) 6 siblings, 1 reply; 101+ messages in thread From: James Bottomley @ 2016-07-27 15:06 UTC (permalink / raw) To: David Woodhouse, Mark Brown, Mimi Zohar, dhowells; +Cc: ksummit-discuss [-- 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 --] ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi 2016-07-27 15:06 ` [Ksummit-discuss] " James Bottomley @ 2016-08-01 10:22 ` Johannes Berg 0 siblings, 0 replies; 101+ messages in thread From: Johannes Berg @ 2016-08-01 10:22 UTC (permalink / raw) To: James Bottomley, David Woodhouse, Mark Brown, Mimi Zohar, dhowells Cc: ksummit-discuss 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 ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi 2016-07-26 14:42 ` David Woodhouse ` (2 preceding siblings ...) 2016-07-27 15:06 ` [Ksummit-discuss] " James Bottomley @ 2016-07-27 15:37 ` David Howells 2016-07-27 16:14 ` James Bottomley 2016-07-27 16:07 ` David Howells ` (2 subsequent siblings) 6 siblings, 1 reply; 101+ messages in thread From: David Howells @ 2016-07-27 15:37 UTC (permalink / raw) To: James Bottomley; +Cc: Mark Brown, ksummit-discuss 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 ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi 2016-07-27 15:37 ` David Howells @ 2016-07-27 16:14 ` James Bottomley 2016-07-27 17:57 ` Andy Lutomirski 0 siblings, 1 reply; 101+ messages in thread From: James Bottomley @ 2016-07-27 16:14 UTC (permalink / raw) To: David Howells; +Cc: Mark Brown, ksummit-discuss 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 ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi 2016-07-27 16:14 ` James Bottomley @ 2016-07-27 17:57 ` Andy Lutomirski 2016-07-27 19:00 ` James Bottomley 0 siblings, 1 reply; 101+ messages in thread From: Andy Lutomirski @ 2016-07-27 17:57 UTC (permalink / raw) To: James Bottomley; +Cc: Mark Brown, ksummit-discuss 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 ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi 2016-07-27 17:57 ` Andy Lutomirski @ 2016-07-27 19:00 ` James Bottomley 2016-07-27 19:20 ` Andy Lutomirski 0 siblings, 1 reply; 101+ messages in thread From: James Bottomley @ 2016-07-27 19:00 UTC (permalink / raw) To: Andy Lutomirski; +Cc: Mark Brown, ksummit-discuss 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 ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi 2016-07-27 19:00 ` James Bottomley @ 2016-07-27 19:20 ` Andy Lutomirski 2016-07-27 19:50 ` James Bottomley 0 siblings, 1 reply; 101+ messages in thread From: Andy Lutomirski @ 2016-07-27 19:20 UTC (permalink / raw) To: James Bottomley; +Cc: Mark Brown, ksummit-discuss 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 ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi 2016-07-27 19:20 ` Andy Lutomirski @ 2016-07-27 19:50 ` James Bottomley 0 siblings, 0 replies; 101+ messages in thread From: James Bottomley @ 2016-07-27 19:50 UTC (permalink / raw) To: Andy Lutomirski; +Cc: Mark Brown, ksummit-discuss 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 > ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi 2016-07-26 14:42 ` David Woodhouse ` (3 preceding siblings ...) 2016-07-27 15:37 ` David Howells @ 2016-07-27 16:07 ` David Howells 2016-07-27 16:25 ` James Bottomley 2016-07-27 16:10 ` David Howells 2016-07-27 16:14 ` David Howells 6 siblings, 1 reply; 101+ messages in thread From: David Howells @ 2016-07-27 16:07 UTC (permalink / raw) To: James Bottomley; +Cc: Mark Brown, ksummit-discuss 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 ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi 2016-07-27 16:07 ` David Howells @ 2016-07-27 16:25 ` James Bottomley 0 siblings, 0 replies; 101+ messages in thread From: James Bottomley @ 2016-07-27 16:25 UTC (permalink / raw) To: David Howells; +Cc: Mark Brown, ksummit-discuss 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 ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi 2016-07-26 14:42 ` David Woodhouse ` (4 preceding siblings ...) 2016-07-27 16:07 ` David Howells @ 2016-07-27 16:10 ` David Howells 2016-07-27 16:14 ` David Howells 6 siblings, 0 replies; 101+ messages in thread From: David Howells @ 2016-07-27 16:10 UTC (permalink / raw) To: James Bottomley; +Cc: Mark Brown, ksummit-discuss 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 ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi 2016-07-26 14:42 ` David Woodhouse ` (5 preceding siblings ...) 2016-07-27 16:10 ` David Howells @ 2016-07-27 16:14 ` David Howells 2016-07-27 16:28 ` James Bottomley 6 siblings, 1 reply; 101+ messages in thread From: David Howells @ 2016-07-27 16:14 UTC (permalink / raw) To: James Bottomley; +Cc: Mark Brown, ksummit-discuss 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 ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi 2016-07-27 16:14 ` David Howells @ 2016-07-27 16:28 ` James Bottomley 2016-07-27 16:36 ` James Bottomley 0 siblings, 1 reply; 101+ messages in thread From: James Bottomley @ 2016-07-27 16:28 UTC (permalink / raw) To: David Howells; +Cc: Mark Brown, ksummit-discuss 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 ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi 2016-07-27 16:28 ` James Bottomley @ 2016-07-27 16:36 ` James Bottomley 2016-07-27 17:20 ` Luis R. Rodriguez ` (2 more replies) 0 siblings, 3 replies; 101+ messages in thread From: James Bottomley @ 2016-07-27 16:36 UTC (permalink / raw) To: David Howells; +Cc: Mark Brown, ksummit-discuss 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 ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi 2016-07-27 16:36 ` James Bottomley @ 2016-07-27 17:20 ` Luis R. Rodriguez 2016-07-27 17:51 ` James Bottomley 2016-07-27 19:37 ` Mimi Zohar 2016-07-29 12:43 ` Ben Hutchings 2 siblings, 1 reply; 101+ messages in thread From: Luis R. Rodriguez @ 2016-07-27 17:20 UTC (permalink / raw) To: James Bottomley; +Cc: Mark Brown, ksummit-discuss 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 ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi 2016-07-27 17:20 ` Luis R. Rodriguez @ 2016-07-27 17:51 ` James Bottomley 2016-07-27 18:57 ` Luis R. Rodriguez 0 siblings, 1 reply; 101+ messages in thread From: James Bottomley @ 2016-07-27 17:51 UTC (permalink / raw) To: Luis R. Rodriguez; +Cc: Mark Brown, ksummit-discuss 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 ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi 2016-07-27 17:51 ` James Bottomley @ 2016-07-27 18:57 ` Luis R. Rodriguez 0 siblings, 0 replies; 101+ messages in thread From: Luis R. Rodriguez @ 2016-07-27 18:57 UTC (permalink / raw) To: James Bottomley; +Cc: Mark Brown, ksummit-discuss 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 ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi 2016-07-27 16:36 ` James Bottomley 2016-07-27 17:20 ` Luis R. Rodriguez @ 2016-07-27 19:37 ` Mimi Zohar 2016-07-27 20:09 ` Andy Lutomirski 2016-07-29 12:43 ` Ben Hutchings 2 siblings, 1 reply; 101+ messages in thread From: Mimi Zohar @ 2016-07-27 19:37 UTC (permalink / raw) To: James Bottomley; +Cc: Mark Brown, ksummit-discuss 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 ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi 2016-07-27 19:37 ` Mimi Zohar @ 2016-07-27 20:09 ` Andy Lutomirski 2016-07-27 22:54 ` Mimi Zohar ` (2 more replies) 0 siblings, 3 replies; 101+ messages in thread From: Andy Lutomirski @ 2016-07-27 20:09 UTC (permalink / raw) To: Mimi Zohar; +Cc: James Bottomley, Mark Brown, ksummit-discuss 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 ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi 2016-07-27 20:09 ` Andy Lutomirski @ 2016-07-27 22:54 ` Mimi Zohar 2016-07-27 23:15 ` Andy Lutomirski 2016-07-28 16:57 ` Jason Cooper 2016-08-02 18:55 ` Andy Lutomirski 2 siblings, 1 reply; 101+ messages in thread From: Mimi Zohar @ 2016-07-27 22:54 UTC (permalink / raw) To: Andy Lutomirski; +Cc: James Bottomley, Mark Brown, ksummit-discuss 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 ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi 2016-07-27 22:54 ` Mimi Zohar @ 2016-07-27 23:15 ` Andy Lutomirski 2016-07-28 3:17 ` Mimi Zohar 0 siblings, 1 reply; 101+ messages in thread From: Andy Lutomirski @ 2016-07-27 23:15 UTC (permalink / raw) To: Mimi Zohar; +Cc: James Bottomley, Mark Brown, ksummit-discuss 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. ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi 2016-07-27 23:15 ` Andy Lutomirski @ 2016-07-28 3:17 ` Mimi Zohar 2016-07-28 3:29 ` Andy Lutomirski 0 siblings, 1 reply; 101+ messages in thread From: Mimi Zohar @ 2016-07-28 3:17 UTC (permalink / raw) To: Andy Lutomirski; +Cc: James Bottomley, Mark Brown, ksummit-discuss 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 ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi 2016-07-28 3:17 ` Mimi Zohar @ 2016-07-28 3:29 ` Andy Lutomirski 0 siblings, 0 replies; 101+ messages in thread From: Andy Lutomirski @ 2016-07-28 3:29 UTC (permalink / raw) To: Mimi Zohar; +Cc: James Bottomley, Mark Brown, ksummit-discuss [-- 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 --] ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi 2016-07-27 20:09 ` Andy Lutomirski 2016-07-27 22:54 ` Mimi Zohar @ 2016-07-28 16:57 ` Jason Cooper 2016-07-29 22:10 ` Mimi Zohar 2016-08-02 18:55 ` Andy Lutomirski 2 siblings, 1 reply; 101+ messages in thread From: Jason Cooper @ 2016-07-28 16:57 UTC (permalink / raw) To: Andy Lutomirski; +Cc: James Bottomley, Mark Brown, ksummit-discuss 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 ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi 2016-07-28 16:57 ` Jason Cooper @ 2016-07-29 22:10 ` Mimi Zohar 2016-07-29 22:25 ` Andy Lutomirski 0 siblings, 1 reply; 101+ messages in thread From: Mimi Zohar @ 2016-07-29 22:10 UTC (permalink / raw) To: Jason Cooper; +Cc: James Bottomley, Mark Brown, ksummit-discuss 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 > ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi 2016-07-29 22:10 ` Mimi Zohar @ 2016-07-29 22:25 ` Andy Lutomirski 2016-07-30 16:36 ` Luis R. Rodriguez 0 siblings, 1 reply; 101+ messages in thread From: Andy Lutomirski @ 2016-07-29 22:25 UTC (permalink / raw) To: Mimi Zohar; +Cc: James Bottomley, Jason Cooper, ksummit-discuss, Mark Brown 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 ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi 2016-07-29 22:25 ` Andy Lutomirski @ 2016-07-30 16:36 ` Luis R. Rodriguez 2016-07-31 3:08 ` Mimi Zohar 0 siblings, 1 reply; 101+ messages in thread From: Luis R. Rodriguez @ 2016-07-30 16:36 UTC (permalink / raw) To: Andy Lutomirski Cc: James Bottomley, Jason Cooper, ksummit-discuss, Mark Brown 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 ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi 2016-07-30 16:36 ` Luis R. Rodriguez @ 2016-07-31 3:08 ` Mimi Zohar 2016-07-31 3:09 ` Andy Lutomirski 0 siblings, 1 reply; 101+ messages in thread From: Mimi Zohar @ 2016-07-31 3:08 UTC (permalink / raw) To: Luis R. Rodriguez Cc: James Bottomley, Mark Brown, Jason Cooper, ksummit-discuss 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 ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi 2016-07-31 3:08 ` Mimi Zohar @ 2016-07-31 3:09 ` Andy Lutomirski 2016-07-31 15:31 ` Mimi Zohar 0 siblings, 1 reply; 101+ messages in thread From: Andy Lutomirski @ 2016-07-31 3:09 UTC (permalink / raw) To: Mimi Zohar; +Cc: James Bottomley, Mark Brown, ksummit-discuss, Jason Cooper [-- 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 --] ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi 2016-07-31 3:09 ` Andy Lutomirski @ 2016-07-31 15:31 ` Mimi Zohar 2016-07-31 16:19 ` Andy Lutomirski 0 siblings, 1 reply; 101+ messages in thread From: Mimi Zohar @ 2016-07-31 15:31 UTC (permalink / raw) To: Andy Lutomirski Cc: James Bottomley, Mark Brown, ksummit-discuss, Jason Cooper 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 ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi 2016-07-31 15:31 ` Mimi Zohar @ 2016-07-31 16:19 ` Andy Lutomirski 2016-07-31 17:28 ` Mimi Zohar 2016-08-01 17:15 ` Luis R. Rodriguez 0 siblings, 2 replies; 101+ messages in thread From: Andy Lutomirski @ 2016-07-31 16:19 UTC (permalink / raw) To: Mimi Zohar; +Cc: James Bottomley, Mark Brown, ksummit-discuss, Jason Cooper 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 ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi 2016-07-31 16:19 ` Andy Lutomirski @ 2016-07-31 17:28 ` Mimi Zohar 2016-07-31 18:20 ` Andy Lutomirski 2016-08-01 17:15 ` Luis R. Rodriguez 1 sibling, 1 reply; 101+ messages in thread From: Mimi Zohar @ 2016-07-31 17:28 UTC (permalink / raw) To: Andy Lutomirski Cc: James Bottomley, Mark Brown, ksummit-discuss, Jason Cooper 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 ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi 2016-07-31 17:28 ` Mimi Zohar @ 2016-07-31 18:20 ` Andy Lutomirski 2016-08-01 1:52 ` Mimi Zohar 2016-08-01 17:29 ` Luis R. Rodriguez 0 siblings, 2 replies; 101+ messages in thread From: Andy Lutomirski @ 2016-07-31 18:20 UTC (permalink / raw) To: Mimi Zohar; +Cc: James Bottomley, Mark Brown, ksummit-discuss, Jason Cooper [-- 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 --] ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi 2016-07-31 18:20 ` Andy Lutomirski @ 2016-08-01 1:52 ` Mimi Zohar 2016-08-01 17:29 ` Luis R. Rodriguez 1 sibling, 0 replies; 101+ messages in thread From: Mimi Zohar @ 2016-08-01 1:52 UTC (permalink / raw) To: Andy Lutomirski Cc: James Bottomley, Mark Brown, ksummit-discuss, Jason Cooper 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 ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi 2016-07-31 18:20 ` Andy Lutomirski 2016-08-01 1:52 ` Mimi Zohar @ 2016-08-01 17:29 ` Luis R. Rodriguez 2016-08-01 17:59 ` Andy Lutomirski 1 sibling, 1 reply; 101+ messages in thread From: Luis R. Rodriguez @ 2016-08-01 17:29 UTC (permalink / raw) To: Andy Lutomirski Cc: Jason Cooper, ksummit-discuss, James Bottomley, Mark Brown 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 ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi 2016-08-01 17:29 ` Luis R. Rodriguez @ 2016-08-01 17:59 ` Andy Lutomirski 2016-08-01 20:23 ` Luis R. Rodriguez 2016-08-01 22:21 ` Mimi Zohar 0 siblings, 2 replies; 101+ messages in thread From: Andy Lutomirski @ 2016-08-01 17:59 UTC (permalink / raw) To: Luis R. Rodriguez Cc: Jason Cooper, ksummit-discuss, James Bottomley, Mark Brown, 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 ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi 2016-08-01 17:59 ` Andy Lutomirski @ 2016-08-01 20:23 ` Luis R. Rodriguez 2016-08-01 20:37 ` Andy Lutomirski 2016-08-01 22:21 ` Mimi Zohar 1 sibling, 1 reply; 101+ messages in thread From: Luis R. Rodriguez @ 2016-08-01 20:23 UTC (permalink / raw) To: Andy Lutomirski Cc: Jason Cooper, ksummit-discuss, James Bottomley, Mark Brown, Andy Lutomirski 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 ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi 2016-08-01 20:23 ` Luis R. Rodriguez @ 2016-08-01 20:37 ` Andy Lutomirski 2016-08-01 20:57 ` Luis R. Rodriguez 0 siblings, 1 reply; 101+ messages in thread From: Andy Lutomirski @ 2016-08-01 20:37 UTC (permalink / raw) To: Luis R. Rodriguez Cc: Jason Cooper, ksummit-discuss, James Bottomley, Mark Brown, 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 ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi 2016-08-01 20:37 ` Andy Lutomirski @ 2016-08-01 20:57 ` Luis R. Rodriguez 2016-08-01 21:14 ` Andy Lutomirski 0 siblings, 1 reply; 101+ messages in thread From: Luis R. Rodriguez @ 2016-08-01 20:57 UTC (permalink / raw) To: Andy Lutomirski, Johannes Berg Cc: Jason Cooper, ksummit-discuss, Kyle McMartin, James Bottomley, Mark Brown, Andy Lutomirski 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 ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi 2016-08-01 20:57 ` Luis R. Rodriguez @ 2016-08-01 21:14 ` Andy Lutomirski 2016-08-01 22:56 ` Jason Cooper 2016-08-02 0:33 ` James Bottomley 0 siblings, 2 replies; 101+ messages in thread From: Andy Lutomirski @ 2016-08-01 21:14 UTC (permalink / raw) To: Luis R. Rodriguez Cc: Jason Cooper, ksummit-discuss, Kyle McMartin, James Bottomley, Mark Brown, Andy Lutomirski, Johannes Berg 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 ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi 2016-08-01 21:14 ` Andy Lutomirski @ 2016-08-01 22:56 ` Jason Cooper 2016-08-01 23:12 ` Andy Lutomirski 2016-08-02 0:33 ` James Bottomley 1 sibling, 1 reply; 101+ messages in thread From: Jason Cooper @ 2016-08-01 22:56 UTC (permalink / raw) To: Andy Lutomirski Cc: ksummit-discuss, Kyle McMartin, James Bottomley, Mark Brown, Andy Lutomirski, Johannes Berg 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. ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi 2016-08-01 22:56 ` Jason Cooper @ 2016-08-01 23:12 ` Andy Lutomirski 0 siblings, 0 replies; 101+ messages in thread From: Andy Lutomirski @ 2016-08-01 23:12 UTC (permalink / raw) To: Jason Cooper Cc: ksummit-discuss, Kyle McMartin, James Bottomley, Mark Brown, Johannes Berg [-- 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 --] ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi 2016-08-01 21:14 ` Andy Lutomirski 2016-08-01 22:56 ` Jason Cooper @ 2016-08-02 0:33 ` James Bottomley [not found] ` <CALCETrXHfUULy-EB13Kbkjwco-2UVgsuRsG+OicZT6_uOkzeqA@mail.gmail.com> 1 sibling, 1 reply; 101+ messages in thread From: James Bottomley @ 2016-08-02 0:33 UTC (permalink / raw) To: Andy Lutomirski, Luis R. Rodriguez Cc: Jason Cooper, ksummit-discuss, Kyle McMartin, Mark Brown, Andy Lutomirski, Johannes Berg 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 ^ permalink raw reply [flat|nested] 101+ messages in thread
[parent not found: <CALCETrXHfUULy-EB13Kbkjwco-2UVgsuRsG+OicZT6_uOkzeqA@mail.gmail.com>]
[parent not found: <CALCETrWqpQV1AyxVx5eTkJiOe3t7ZFpSAuN2RG3JNHD-gqm0uA@mail.gmail.com>]
* Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi [not found] ` <CALCETrWqpQV1AyxVx5eTkJiOe3t7ZFpSAuN2RG3JNHD-gqm0uA@mail.gmail.com> @ 2016-08-02 0:48 ` Andy Lutomirski 2016-08-02 1:13 ` James Bottomley 0 siblings, 1 reply; 101+ messages in thread From: Andy Lutomirski @ 2016-08-02 0:48 UTC (permalink / raw) To: James Bottomley Cc: Jason Cooper, ksummit-discuss, Kyle McMartin, Mark Brown, Johannes Berg [-- 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 --] ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi 2016-08-02 0:48 ` Andy Lutomirski @ 2016-08-02 1:13 ` James Bottomley 2016-08-02 1:23 ` Andy Lutomirski 0 siblings, 1 reply; 101+ messages in thread From: James Bottomley @ 2016-08-02 1:13 UTC (permalink / raw) To: Andy Lutomirski Cc: Johannes Berg, Kyle McMartin, Jason Cooper, ksummit-discuss, Mark Brown 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 ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi 2016-08-02 1:13 ` James Bottomley @ 2016-08-02 1:23 ` Andy Lutomirski 2016-08-02 18:12 ` James Bottomley 0 siblings, 1 reply; 101+ messages in thread From: Andy Lutomirski @ 2016-08-02 1:23 UTC (permalink / raw) To: James Bottomley Cc: Johannes Berg, Kyle McMartin, Jason Cooper, ksummit-discuss, Mark Brown 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 ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi 2016-08-02 1:23 ` Andy Lutomirski @ 2016-08-02 18:12 ` James Bottomley 0 siblings, 0 replies; 101+ messages in thread From: James Bottomley @ 2016-08-02 18:12 UTC (permalink / raw) To: Andy Lutomirski Cc: Johannes Berg, Kyle McMartin, Jason Cooper, ksummit-discuss, Mark Brown 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 ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi 2016-08-01 17:59 ` Andy Lutomirski 2016-08-01 20:23 ` Luis R. Rodriguez @ 2016-08-01 22:21 ` Mimi Zohar 2016-08-01 22:36 ` Andy Lutomirski 1 sibling, 1 reply; 101+ messages in thread From: Mimi Zohar @ 2016-08-01 22:21 UTC (permalink / raw) To: Andy Lutomirski Cc: Jason Cooper, ksummit-discuss, James Bottomley, Mark Brown, Andy Lutomirski 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 ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi 2016-08-01 22:21 ` Mimi Zohar @ 2016-08-01 22:36 ` Andy Lutomirski 2016-08-01 23:02 ` Mimi Zohar 2016-08-01 23:04 ` Jason Cooper 0 siblings, 2 replies; 101+ messages in thread From: Andy Lutomirski @ 2016-08-01 22:36 UTC (permalink / raw) To: Mimi Zohar Cc: Jason Cooper, ksummit-discuss, James Bottomley, Mark Brown, 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 ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi 2016-08-01 22:36 ` Andy Lutomirski @ 2016-08-01 23:02 ` Mimi Zohar 2016-08-01 23:04 ` Jason Cooper 1 sibling, 0 replies; 101+ messages in thread From: Mimi Zohar @ 2016-08-01 23:02 UTC (permalink / raw) To: Andy Lutomirski Cc: Jason Cooper, ksummit-discuss, James Bottomley, Mark Brown, Andy Lutomirski 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 ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi 2016-08-01 22:36 ` Andy Lutomirski 2016-08-01 23:02 ` Mimi Zohar @ 2016-08-01 23:04 ` Jason Cooper 2016-08-01 23:13 ` Andy Lutomirski 1 sibling, 1 reply; 101+ messages in thread From: Jason Cooper @ 2016-08-01 23:04 UTC (permalink / raw) To: Andy Lutomirski Cc: James Bottomley, Andy Lutomirski, Mark Brown, ksummit-discuss 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. ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi 2016-08-01 23:04 ` Jason Cooper @ 2016-08-01 23:13 ` Andy Lutomirski 2016-08-01 23:30 ` Jason Cooper 0 siblings, 1 reply; 101+ messages in thread From: Andy Lutomirski @ 2016-08-01 23:13 UTC (permalink / raw) To: Jason Cooper; +Cc: James Bottomley, Mark Brown, ksummit-discuss [-- 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 --] ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi 2016-08-01 23:13 ` Andy Lutomirski @ 2016-08-01 23:30 ` Jason Cooper [not found] ` <CALCETrWDsMdU2-AWQC4wYvotnNd2ydWT15Ckq0nZaNRJZOtZ-g@mail.gmail.com> 0 siblings, 1 reply; 101+ messages in thread From: Jason Cooper @ 2016-08-01 23:30 UTC (permalink / raw) To: Andy Lutomirski; +Cc: James Bottomley, Mark Brown, ksummit-discuss 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. ^ permalink raw reply [flat|nested] 101+ messages in thread
[parent not found: <CALCETrWDsMdU2-AWQC4wYvotnNd2ydWT15Ckq0nZaNRJZOtZ-g@mail.gmail.com>]
[parent not found: <CALCETrW-P8+yGuEgM2BT+aCfZqJ=ekB2Xsz+4xhWtdRpprJHNw@mail.gmail.com>]
* Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi [not found] ` <CALCETrW-P8+yGuEgM2BT+aCfZqJ=ekB2Xsz+4xhWtdRpprJHNw@mail.gmail.com> @ 2016-08-01 23:45 ` Andy Lutomirski 2016-08-02 12:20 ` Jason Cooper 0 siblings, 1 reply; 101+ messages in thread From: Andy Lutomirski @ 2016-08-01 23:45 UTC (permalink / raw) To: Jason Cooper; +Cc: James Bottomley, Mark Brown, ksummit-discuss [-- 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 --] ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi 2016-08-01 23:45 ` Andy Lutomirski @ 2016-08-02 12:20 ` Jason Cooper [not found] ` <CALCETrVEY=opRPGKy=P9h8s+TC_K19WnBJ2svXT+=_FnqRF1Mw@mail.gmail.com> 0 siblings, 1 reply; 101+ messages in thread From: Jason Cooper @ 2016-08-02 12:20 UTC (permalink / raw) To: Andy Lutomirski; +Cc: James Bottomley, Mark Brown, ksummit-discuss 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. ^ permalink raw reply [flat|nested] 101+ messages in thread
[parent not found: <CALCETrVEY=opRPGKy=P9h8s+TC_K19WnBJ2svXT+=_FnqRF1Mw@mail.gmail.com>]
[parent not found: <CALCETrVZtn_SmeN1YX9_+2g+bEAHsfJJ7KQH7-eC_mU3O+0x2w@mail.gmail.com>]
* Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi [not found] ` <CALCETrVZtn_SmeN1YX9_+2g+bEAHsfJJ7KQH7-eC_mU3O+0x2w@mail.gmail.com> @ 2016-08-02 15:07 ` Andy Lutomirski 2016-08-03 16:44 ` Jason Cooper 0 siblings, 1 reply; 101+ messages in thread From: Andy Lutomirski @ 2016-08-02 15:07 UTC (permalink / raw) To: Jason Cooper; +Cc: James Bottomley, Mark Brown, ksummit-discuss [-- 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 --] ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi 2016-08-02 15:07 ` Andy Lutomirski @ 2016-08-03 16:44 ` Jason Cooper 2016-08-03 17:20 ` Andy Lutomirski 0 siblings, 1 reply; 101+ messages in thread From: Jason Cooper @ 2016-08-03 16:44 UTC (permalink / raw) To: Andy Lutomirski; +Cc: James Bottomley, Mark Brown, ksummit-discuss 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. ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi 2016-08-03 16:44 ` Jason Cooper @ 2016-08-03 17:20 ` Andy Lutomirski 2016-08-03 17:50 ` Jason Cooper 0 siblings, 1 reply; 101+ messages in thread From: Andy Lutomirski @ 2016-08-03 17:20 UTC (permalink / raw) To: Jason Cooper; +Cc: James Bottomley, Mark Brown, ksummit-discuss 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. ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi 2016-08-03 17:20 ` Andy Lutomirski @ 2016-08-03 17:50 ` Jason Cooper 0 siblings, 0 replies; 101+ messages in thread From: Jason Cooper @ 2016-08-03 17:50 UTC (permalink / raw) To: Andy Lutomirski; +Cc: James Bottomley, Mark Brown, ksummit-discuss 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. ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi 2016-07-31 16:19 ` Andy Lutomirski 2016-07-31 17:28 ` Mimi Zohar @ 2016-08-01 17:15 ` Luis R. Rodriguez 1 sibling, 0 replies; 101+ messages in thread From: Luis R. Rodriguez @ 2016-08-01 17:15 UTC (permalink / raw) To: Andy Lutomirski, David Howells Cc: Jason Cooper, ksummit-discuss, James Bottomley, Mark Brown 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 ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi 2016-07-27 20:09 ` Andy Lutomirski 2016-07-27 22:54 ` Mimi Zohar 2016-07-28 16:57 ` Jason Cooper @ 2016-08-02 18:55 ` Andy Lutomirski 2016-08-02 19:02 ` Ard Biesheuvel 2 siblings, 1 reply; 101+ messages in thread From: Andy Lutomirski @ 2016-08-02 18:55 UTC (permalink / raw) To: Mimi Zohar; +Cc: James Bottomley, Mark Brown, ksummit-discuss 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 ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi 2016-08-02 18:55 ` Andy Lutomirski @ 2016-08-02 19:02 ` Ard Biesheuvel 2016-08-02 19:08 ` Andy Lutomirski 0 siblings, 1 reply; 101+ messages in thread From: Ard Biesheuvel @ 2016-08-02 19:02 UTC (permalink / raw) To: Andy Lutomirski; +Cc: James Bottomley, Mark Brown, ksummit-discuss 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. ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi 2016-08-02 19:02 ` Ard Biesheuvel @ 2016-08-02 19:08 ` Andy Lutomirski 2016-08-02 19:14 ` Ard Biesheuvel 0 siblings, 1 reply; 101+ messages in thread From: Andy Lutomirski @ 2016-08-02 19:08 UTC (permalink / raw) To: Ard Biesheuvel; +Cc: James Bottomley, Mark Brown, ksummit-discuss 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 ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi 2016-08-02 19:08 ` Andy Lutomirski @ 2016-08-02 19:14 ` Ard Biesheuvel 2016-08-02 19:17 ` Andy Lutomirski 0 siblings, 1 reply; 101+ messages in thread From: Ard Biesheuvel @ 2016-08-02 19:14 UTC (permalink / raw) To: Andy Lutomirski; +Cc: James Bottomley, Mark Brown, ksummit-discuss 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 :-) ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi 2016-08-02 19:14 ` Ard Biesheuvel @ 2016-08-02 19:17 ` Andy Lutomirski 2016-08-02 19:20 ` Ard Biesheuvel 0 siblings, 1 reply; 101+ messages in thread From: Andy Lutomirski @ 2016-08-02 19:17 UTC (permalink / raw) To: Ard Biesheuvel; +Cc: James Bottomley, Mark Brown, ksummit-discuss [-- 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 --] ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi 2016-08-02 19:17 ` Andy Lutomirski @ 2016-08-02 19:20 ` Ard Biesheuvel 2016-08-02 20:22 ` Ard Biesheuvel 0 siblings, 1 reply; 101+ messages in thread From: Ard Biesheuvel @ 2016-08-02 19:20 UTC (permalink / raw) To: Andy Lutomirski; +Cc: James Bottomley, Mark Brown, ksummit-discuss 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 ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi 2016-08-02 19:20 ` Ard Biesheuvel @ 2016-08-02 20:22 ` Ard Biesheuvel 0 siblings, 0 replies; 101+ messages in thread From: Ard Biesheuvel @ 2016-08-02 20:22 UTC (permalink / raw) To: Andy Lutomirski; +Cc: James Bottomley, Mark Brown, ksummit-discuss 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. ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi 2016-07-27 16:36 ` James Bottomley 2016-07-27 17:20 ` Luis R. Rodriguez 2016-07-27 19:37 ` Mimi Zohar @ 2016-07-29 12:43 ` Ben Hutchings 2016-07-29 17:57 ` Mimi Zohar 2 siblings, 1 reply; 101+ messages in thread From: Ben Hutchings @ 2016-07-29 12:43 UTC (permalink / raw) To: James Bottomley, David Howells; +Cc: Mark Brown, ksummit-discuss [-- 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 --] ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi 2016-07-29 12:43 ` Ben Hutchings @ 2016-07-29 17:57 ` Mimi Zohar 0 siblings, 0 replies; 101+ messages in thread From: Mimi Zohar @ 2016-07-29 17:57 UTC (permalink / raw) To: Ben Hutchings; +Cc: James Bottomley, Mark Brown, ksummit-discuss 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 ^ permalink raw reply [flat|nested] 101+ messages in thread
end of thread, other threads:[~2016-08-12 13:12 UTC | newest] Thread overview: 101+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-08-04 15:26 [Ksummit-discuss] Last minute nominations: mcgrof and toshi Luis R. Rodriguez 2015-08-04 22:20 ` Toshi Kani 2016-07-15 19:50 ` Mimi Zohar 2016-07-15 19:57 ` Mimi Zohar 2016-07-16 0:52 ` Mark Brown 2016-07-26 14:42 ` David Woodhouse 2016-07-27 14:04 ` [Ksummit-discuss] [TECH TOPIC] Signature management - keys, modules, firmware, was: " Jason Cooper 2016-07-27 14:58 ` Mark Rutland 2016-07-27 18:17 ` Stephen Hemminger 2016-07-27 18:36 ` Andy Lutomirski 2016-07-29 12:29 ` Ben Hutchings 2016-08-05 17:16 ` Mimi Zohar 2016-08-05 18:24 ` Ben Hutchings 2016-08-02 12:54 ` Linus Walleij 2016-08-02 14:00 ` Jason Cooper 2016-08-02 14:09 ` David Woodhouse [not found] ` <CALCETrUjn7TeGbS4TQ+OFih-nby2Rh54i5177MOwqjTYDBMO=A@mail.gmail.com> [not found] ` <CALCETrU6aQ5PR_+M7QHkTWos6i6vVS2nvEQDwr5ktBkWu-5MKw@mail.gmail.com> [not found] ` <CALCETrW8uRK4cuQ+B6NPcO0pY-=-HRDf4LZk4xv2QdPzNEvMCg@mail.gmail.com> [not found] ` <CALCETrW_mQLmR6g_Ar8Nnpr7CRFZhth=Hj9C901Gj7_WSp=yEQ@mail.gmail.com> 2016-08-02 14:53 ` Andy Lutomirski 2016-08-02 14:13 ` James Bottomley 2016-08-03 9:47 ` Linus Walleij 2016-08-03 10:00 ` Jiri Kosina 2016-08-03 10:28 ` Jani Nikula 2016-08-03 10:41 ` Linus Walleij 2016-08-03 11:18 ` Jani Nikula 2016-08-03 15:19 ` Jason Cooper 2016-08-12 12:38 ` Vinod Koul 2016-08-12 12:39 ` David Woodhouse 2016-08-12 12:54 ` Andy Lutomirski 2016-08-12 13:00 ` David Woodhouse 2016-08-12 13:12 ` Vinod Koul 2016-07-27 14:08 ` David Howells 2016-07-27 14:10 ` Ard Biesheuvel 2016-07-27 14:23 ` Mark Brown 2016-07-27 15:06 ` [Ksummit-discuss] " James Bottomley 2016-08-01 10:22 ` Johannes Berg 2016-07-27 15:37 ` David Howells 2016-07-27 16:14 ` James Bottomley 2016-07-27 17:57 ` Andy Lutomirski 2016-07-27 19:00 ` James Bottomley 2016-07-27 19:20 ` Andy Lutomirski 2016-07-27 19:50 ` James Bottomley 2016-07-27 16:07 ` David Howells 2016-07-27 16:25 ` James Bottomley 2016-07-27 16:10 ` David Howells 2016-07-27 16:14 ` David Howells 2016-07-27 16:28 ` James Bottomley 2016-07-27 16:36 ` James Bottomley 2016-07-27 17:20 ` Luis R. Rodriguez 2016-07-27 17:51 ` James Bottomley 2016-07-27 18:57 ` Luis R. Rodriguez 2016-07-27 19:37 ` Mimi Zohar 2016-07-27 20:09 ` Andy Lutomirski 2016-07-27 22:54 ` Mimi Zohar 2016-07-27 23:15 ` Andy Lutomirski 2016-07-28 3:17 ` Mimi Zohar 2016-07-28 3:29 ` Andy Lutomirski 2016-07-28 16:57 ` Jason Cooper 2016-07-29 22:10 ` Mimi Zohar 2016-07-29 22:25 ` Andy Lutomirski 2016-07-30 16:36 ` Luis R. Rodriguez 2016-07-31 3:08 ` Mimi Zohar 2016-07-31 3:09 ` Andy Lutomirski 2016-07-31 15:31 ` Mimi Zohar 2016-07-31 16:19 ` Andy Lutomirski 2016-07-31 17:28 ` Mimi Zohar 2016-07-31 18:20 ` Andy Lutomirski 2016-08-01 1:52 ` Mimi Zohar 2016-08-01 17:29 ` Luis R. Rodriguez 2016-08-01 17:59 ` Andy Lutomirski 2016-08-01 20:23 ` Luis R. Rodriguez 2016-08-01 20:37 ` Andy Lutomirski 2016-08-01 20:57 ` Luis R. Rodriguez 2016-08-01 21:14 ` Andy Lutomirski 2016-08-01 22:56 ` Jason Cooper 2016-08-01 23:12 ` Andy Lutomirski 2016-08-02 0:33 ` James Bottomley [not found] ` <CALCETrXHfUULy-EB13Kbkjwco-2UVgsuRsG+OicZT6_uOkzeqA@mail.gmail.com> [not found] ` <CALCETrWqpQV1AyxVx5eTkJiOe3t7ZFpSAuN2RG3JNHD-gqm0uA@mail.gmail.com> 2016-08-02 0:48 ` Andy Lutomirski 2016-08-02 1:13 ` James Bottomley 2016-08-02 1:23 ` Andy Lutomirski 2016-08-02 18:12 ` James Bottomley 2016-08-01 22:21 ` Mimi Zohar 2016-08-01 22:36 ` Andy Lutomirski 2016-08-01 23:02 ` Mimi Zohar 2016-08-01 23:04 ` Jason Cooper 2016-08-01 23:13 ` Andy Lutomirski 2016-08-01 23:30 ` Jason Cooper [not found] ` <CALCETrWDsMdU2-AWQC4wYvotnNd2ydWT15Ckq0nZaNRJZOtZ-g@mail.gmail.com> [not found] ` <CALCETrW-P8+yGuEgM2BT+aCfZqJ=ekB2Xsz+4xhWtdRpprJHNw@mail.gmail.com> 2016-08-01 23:45 ` Andy Lutomirski 2016-08-02 12:20 ` Jason Cooper [not found] ` <CALCETrVEY=opRPGKy=P9h8s+TC_K19WnBJ2svXT+=_FnqRF1Mw@mail.gmail.com> [not found] ` <CALCETrVZtn_SmeN1YX9_+2g+bEAHsfJJ7KQH7-eC_mU3O+0x2w@mail.gmail.com> 2016-08-02 15:07 ` Andy Lutomirski 2016-08-03 16:44 ` Jason Cooper 2016-08-03 17:20 ` Andy Lutomirski 2016-08-03 17:50 ` Jason Cooper 2016-08-01 17:15 ` Luis R. Rodriguez 2016-08-02 18:55 ` Andy Lutomirski 2016-08-02 19:02 ` Ard Biesheuvel 2016-08-02 19:08 ` Andy Lutomirski 2016-08-02 19:14 ` Ard Biesheuvel 2016-08-02 19:17 ` Andy Lutomirski 2016-08-02 19:20 ` Ard Biesheuvel 2016-08-02 20:22 ` Ard Biesheuvel 2016-07-29 12:43 ` Ben Hutchings 2016-07-29 17:57 ` Mimi Zohar
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.