From lhinds at redhat.com Fri May 4 09:53:03 2018 From: lhinds at redhat.com (Luke Hinds) Date: Fri, 4 May 2018 10:53:03 +0100 Subject: [Rh-moc-bare-metal] Further discussion on bare metal provisioning In-Reply-To: <59FBE487-44E2-456C-986F-64EA3B2455DC@ll.mit.edu> References: <59FBE487-44E2-456C-986F-64EA3B2455DC@ll.mit.edu> Message-ID: Hi Charlie, Had some time to read over the slides `docs/llsrc-keylime-acsac-v6.ppt` for keylime and have a few questions: vTPM , Keylime sits on Xen hypervisor here, what is the state of play with KVM/QEMU? You have the question in slide #3 'Cloud Trust Challenges' - "After I provision it, how do I know my cloud machine is still good?", but I could not spot an answer (might be my own misread). This was one of the concerns that came up in openstack/nova when TPM was first positioned. Nodes were designated as 'trusted' based on last boot, but that boot may have been some time ago and the machine may have been compromised since then. Do you have a proposal on how to address this 'rear view mirror' level of Trust, that degrades after the last known good boot? My own ideas around this have been that Trust should be a weighted factor somehow, where attributes such as time since last boot are combined with perhaps post boot factors such as file integrity hashes, os packages are updated. Then a OP can weight that level of trust themselves for different workloads and their required privacy level. This is where I favour an open API approach, so TPM can be a factor in what is 'trust', more than an complete arbiter. Regards, Luke On Mon, Apr 23, 2018 at 11:32 PM, Munson, Charles - 0553 - MITLL < Charles.Munson at ll.mit.edu> wrote: > Hello, > > > > We are definitely interested in working towards making Keylime a more > easily supportable attestation infrastructure. As per the notes from the > roundtable discussion we had a few weeks ago, outlined are some goals for > Keylime and attestation: > > > > *Keylime and attestation.* > > *? We believe Keylime could fill a very useful niche upstream, especially > in that the only project that rivals it -- Intel's OpenCIT -- appears to be > open-source in name only and probably not truly open to outside > contributors. We should therefore as a group devote some effort to > packaging Keylime, building a CI infrastructure around it, and generally > making it reasonable to use in a production environment. We should also:* > > *o do the work necessary to integrate it with the Fedora early boot > components;* > > *o consider whether it should find a home with an existing upstream > project like Katello (part of Satellite) or FreeIPA (Red Hat identity > management project);* > > *o Examine -- as a research project? -- how to integrate attestation via > Keylime with the Ironic state machine* > > > > We have released a new version of Keylime today (v2.3.3) that includes > IPsec configuration + documentation, as well as some readme improvements: > https://github.com/mit-ll/python-keylime. There is also documentation > available in the /doc/ directory as we pointed out earlier (including our > ACSAC paper and presentation), and we would be happy to answer any > questions you may have. > > > > We have also opened up an issue related to integrating Keylime with the > Fedora early boot components for easier collaboration, especially if Ali > chooses to work on this during the summer: https://github.com/mit-ll/ > python-keylime/issues/6 > > > > Additionally, as we discussed with Peter during the Roundtable, we have > opened an issue to investigate adding TPM 2.0 support to Keylime (see > https://github.com/mit-ll/python-keylime/issues/5) instead of relying > only on the older TPM 1.2. > > > > We would like to discuss the future steps towards making Keylime more > production-ready so we can complete the goals outlined above, and we are > certainly open to supporting this effort from our side as well. We can > also set up a telecom if you are interested in discussing this further. > > > > Best regards, > > Charlie > > > > ---- > > *Charles Munson, Ph.D.* (*x9331*) > > Technical Staff > > charles.munson at ll.mit.edu > > Secure, Resilient Systems and Technology (5-53) > > MIT Lincoln Laboratory > > > > > > > > From: on behalf of Hugh Brock < > hbrock at redhat.com> > > Date: Monday, April 9, 2018 at 5:19 PM > > To: "rh-moc-bare-metal at redhat.com" > > Subject: [Rh-moc-bare-metal] Further discussion on bare metal provisioning > > > > Folks, > > > > As you have probably seen, I have added you to a new mailing list for the > purpose of following up on Friday's bare metal provisioning workshop. > Please feel free to comment on the summary document Orran and I prepared, > here: > > > > https://docs.google.com/document/d/1JNmhqCpoG1irj9mb4o46VpISPvN8E > 7DAICFiT7BwmVk/edit?usp=sharing > > > > Thanks for your interest. We'll have further updates forthcoming. > > > > Take care, > > --Hugh > > -- > > Hugh Brock, mailto:hbrock at redhat.com > > Director of Engineering, Boston University Research Initiatives > > --- > > "I know that you believe you understand what you think I said, but I'm not > sure you realize that what you heard is not what I meant." --Robert > McCloskey > > _______________________________________________ > Rh-moc-bare-metal mailing list > Rh-moc-bare-metal at redhat.com > https://www.redhat.com/mailman/listinfo/rh-moc-bare-metal > > -- Luke Hinds | NFV Partner Engineering | CTO Office | Red Hat e: lhinds at redhat.com | irc: lhinds @freenode | t: +44 12 52 36 2483 -------------- next part -------------- An HTML attachment was scrubbed... URL: From lhinds at redhat.com Fri May 4 10:52:25 2018 From: lhinds at redhat.com (Luke Hinds) Date: Fri, 4 May 2018 11:52:25 +0100 Subject: [Rh-moc-bare-metal] Further discussion on bare metal provisioning In-Reply-To: References: <59FBE487-44E2-456C-986F-64EA3B2455DC@ll.mit.edu> Message-ID: Sorry for the list noise, I found `tci-acm.pdf` paper now, so reading up on 'system integrity monitoring' and will follow up after - attached for anyone else interested. On Fri, May 4, 2018 at 10:53 AM, Luke Hinds wrote: > Hi Charlie, > > Had some time to read over the slides `docs/llsrc-keylime-acsac-v6.ppt` > for keylime and have a few questions: > > vTPM , Keylime sits on Xen hypervisor here, what is the state of play with > KVM/QEMU? > > You have the question in slide #3 'Cloud Trust Challenges' - "After I > provision it, how do I know my cloud machine is still good?", but I could > not spot an answer (might be my own misread). > > This was one of the concerns that came up in openstack/nova when TPM was > first positioned. Nodes were designated as 'trusted' based on last boot, > but that boot may have been some time ago and the machine may have been > compromised since then. > > Do you have a proposal on how to address this 'rear view mirror' level of > Trust, that degrades after the last known good boot? > > My own ideas around this have been that Trust should be a weighted factor > somehow, where attributes such as time since last boot are combined with > perhaps post boot factors such as file integrity hashes, os packages are > updated. Then a OP can weight that level of trust themselves for different > workloads and their required privacy level. This is where I favour an open > API approach, so TPM can be a factor in what is 'trust', more than an > complete arbiter. > > Regards, > > Luke > > > On Mon, Apr 23, 2018 at 11:32 PM, Munson, Charles - 0553 - MITLL < > Charles.Munson at ll.mit.edu> wrote: > >> Hello, >> >> >> >> We are definitely interested in working towards making Keylime a more >> easily supportable attestation infrastructure. As per the notes from the >> roundtable discussion we had a few weeks ago, outlined are some goals for >> Keylime and attestation: >> >> >> >> *Keylime and attestation.* >> >> *? We believe Keylime could fill a very useful niche upstream, especially >> in that the only project that rivals it -- Intel's OpenCIT -- appears to be >> open-source in name only and probably not truly open to outside >> contributors. We should therefore as a group devote some effort to >> packaging Keylime, building a CI infrastructure around it, and generally >> making it reasonable to use in a production environment. We should also:* >> >> *o do the work necessary to integrate it with the Fedora early boot >> components;* >> >> *o consider whether it should find a home with an existing upstream >> project like Katello (part of Satellite) or FreeIPA (Red Hat identity >> management project);* >> >> *o Examine -- as a research project? -- how to integrate attestation via >> Keylime with the Ironic state machine* >> >> >> >> We have released a new version of Keylime today (v2.3.3) that includes >> IPsec configuration + documentation, as well as some readme improvements: >> https://github.com/mit-ll/python-keylime. There is also documentation >> available in the /doc/ directory as we pointed out earlier (including our >> ACSAC paper and presentation), and we would be happy to answer any >> questions you may have. >> >> >> >> We have also opened up an issue related to integrating Keylime with the >> Fedora early boot components for easier collaboration, especially if Ali >> chooses to work on this during the summer: https://github.com/mit-ll/pyth >> on-keylime/issues/6 >> >> >> >> Additionally, as we discussed with Peter during the Roundtable, we have >> opened an issue to investigate adding TPM 2.0 support to Keylime (see >> https://github.com/mit-ll/python-keylime/issues/5) instead of relying >> only on the older TPM 1.2. >> >> >> >> We would like to discuss the future steps towards making Keylime more >> production-ready so we can complete the goals outlined above, and we are >> certainly open to supporting this effort from our side as well. We can >> also set up a telecom if you are interested in discussing this further. >> >> >> >> Best regards, >> >> Charlie >> >> >> >> ---- >> >> *Charles Munson, Ph.D.* (*x9331*) >> >> Technical Staff >> >> charles.munson at ll.mit.edu >> >> Secure, Resilient Systems and Technology (5-53) >> >> MIT Lincoln Laboratory >> >> >> >> >> >> >> >> From: on behalf of Hugh Brock < >> hbrock at redhat.com> >> >> Date: Monday, April 9, 2018 at 5:19 PM >> >> To: "rh-moc-bare-metal at redhat.com" >> >> Subject: [Rh-moc-bare-metal] Further discussion on bare metal provisioning >> >> >> >> Folks, >> >> >> >> As you have probably seen, I have added you to a new mailing list for the >> purpose of following up on Friday's bare metal provisioning workshop. >> Please feel free to comment on the summary document Orran and I prepared, >> here: >> >> >> >> https://docs.google.com/document/d/1JNmhqCpoG1irj9mb4o46VpIS >> PvN8E7DAICFiT7BwmVk/edit?usp=sharing >> >> >> >> Thanks for your interest. We'll have further updates forthcoming. >> >> >> >> Take care, >> >> --Hugh >> >> -- >> >> Hugh Brock, mailto:hbrock at redhat.com >> >> Director of Engineering, Boston University Research Initiatives >> >> --- >> >> "I know that you believe you understand what you think I said, but I'm >> not sure you realize that what you heard is not what I meant." --Robert >> McCloskey >> >> _______________________________________________ >> Rh-moc-bare-metal mailing list >> Rh-moc-bare-metal at redhat.com >> https://www.redhat.com/mailman/listinfo/rh-moc-bare-metal >> >> > > > -- > Luke Hinds | NFV Partner Engineering | CTO Office | Red Hat > e: lhinds at redhat.com | irc: lhinds @freenode | t: +44 12 52 36 2483 > -- Luke Hinds | NFV Partner Engineering | CTO Office | Red Hat e: lhinds at redhat.com | irc: lhinds @freenode | t: +44 12 52 36 2483 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: tci-acm.pdf Type: application/pdf Size: 496138 bytes Desc: not available URL: From nabil at ll.mit.edu Fri May 4 20:14:41 2018 From: nabil at ll.mit.edu (Schear, Nabil - 0553 - MITLL) Date: Fri, 4 May 2018 20:14:41 +0000 Subject: [Rh-moc-bare-metal] Further discussion on bare metal provisioning In-Reply-To: References: <59FBE487-44E2-456C-986F-64EA3B2455DC@ll.mit.edu> Message-ID: <365B2E88-F66A-46F2-9671-84C2D3B1FE4E@ll.mit.edu> Luke, There's quite a lot to discuss in your questions.? So, it might make sense to talk offline about all the details.? ?That said, I'll give some quick responses: Keylime only works with the vTPM implementation in Xen.? This implementation was done a few years ago by the government/industry folks and Xen ingested it more or less as is.? Some of the same people, (in this case IBM), ported the same to qemu and then tried to upstream it.? The qemu folks didn't want to ingest 50K+ lines of code into their project and therefore own and need to maintain it.? So, they said no.? Not to be beaten, IBM then set out on a multiyear effort to create interfaces in qemu using CUSE (like FUSE for fs, but instead of char devices in userspace).? They then built a new TPM emulator that could speak CUSE.? https://github.com/stefanberger/swtpm? So, you could run a bunch of tpm emulators in your KVM host and then use CUSE to wire them up to individual vms.? I've never tried to set this up, but it appears to exist (if you look at stefan's other repos, you can see other tools like libvirt that they've patched up to make this work).? I believe it's their hope that they can upstream this into qemu because the TPM emulator isn't included.? I don't know where that is in the process.? The security model for vtpm in KVM in this way is a good bit different than how it's done in Xen and I think that Xen's approach is superior.? At a high level, there's no reason that both swtpm and keylime couldn't be ported to work with one another.? There's some additional features that we require that I don't know that they have.? But, not too hard to add.? Nothing fundamental. Now as to timeliness of attestation?Attestation is distinctly a statement about the past.? In the case of a physical TPM, the quote probably at least half a second old by the time you can give a signed version to someone for attestation.? There are a variety of methods in the literature for dealing with this that I can talk about offline.? Quick take: this is still an unsolved problem generally.? keylime is merely a tool for attesting TPM state and using it for key agreement.? We rely on a completely separate set of mechanisms (e.g., coreboot, trusted grub, IMA, etc.) for actually recording integrity measurements into the TPM.? Keylime supports repeatedly asking for attestations from a node.? This is so that whatever integrity measurement mechanism you use to record things can be acted upon quickly.? If you only do boot-time measurements (e.g., by using trustedgrub or tboot), then all this will net you is the ability to detect if the machine has been rebooted into an unknown state.? If you're using IMA to measure binaries as they run, then keylime can react to an unknown binary being executed.? If you're doing some super cool thing like LKIM, then keylime can handle that too. One last thing: the TCG had a concept for this additional attestation metadata called OpenPTS.? I think strongswan is the only thing out there that actually uses it.? I've heard from others that they're trying to re-design it to be better.? Some of the same folks behind the Xen vTPM implementation have a proposal for this: https://arxiv.org/abs/1709.10147 Quick response complete =) Best, -Nabil -- Nabil Schear, Ph.D. Senior Staff, Secure Resilient Systems and Technology Group MIT Lincoln Laboratory, 244 Wood St, Lexington, MA 02420 Tel: 781-981-5744 Office: C-290F From: on behalf of Luke Hinds Date: Friday, May 4, 2018 at 5:53 AMEDT To: "Munson, Charles - 0553 - MITLL" Cc: "rh-moc-bare-metal at redhat.com" Subject: Re: [Rh-moc-bare-metal] Further discussion on bare metal provisioning Hi Charlie, Had some time to read over the slides `docs/llsrc-keylime-acsac-v6.ppt` for keylime and have a few questions: vTPM , Keylime sits on Xen hypervisor here, what is the state of play with KVM/QEMU? You have the question in slide #3 'Cloud Trust Challenges' - "After I provision it, how do I know my cloud machine is still good?", but I could not spot an answer (might be my own misread). This was one of the concerns that came up in openstack/nova when TPM was first positioned. Nodes were designated as 'trusted' based on last boot, but that boot may have been some time ago and the machine may have been compromised since then. Do you have a proposal on how to address this 'rear view mirror' level of Trust, that degrades after the last known good boot? My own ideas around this have been that Trust should be a weighted factor somehow, where attributes such as time since last boot are combined with perhaps post boot factors such as file integrity hashes, os packages are updated. Then a OP can weight that level of trust themselves for different workloads and their required privacy level. This is where I favour an open API approach, so TPM can be a factor in what is 'trust', more than an complete arbiter. Regards, Luke On Mon, Apr 23, 2018 at 11:32 PM, Munson, Charles - 0553 - MITLL wrote: Hello, We are definitely interested in working towards making Keylime a more easily supportable attestation infrastructure. As per the notes from the roundtable discussion we had a few weeks ago, outlined are some goals for Keylime and attestation: Keylime and attestation. ? We believe Keylime could fill a very useful niche upstream, especially in that the only project that rivals it -- Intel's OpenCIT -- appears to be open-source in name only and probably not truly open to outside contributors. We should therefore as a group devote some effort to packaging Keylime, building a CI infrastructure around it, and generally making it reasonable to use in a production environment. We should also: o do the work necessary to integrate it with the Fedora early boot components; o consider whether it should find a home with an existing upstream project like Katello (part of Satellite) or FreeIPA (Red Hat identity management project); o Examine -- as a research project? -- how to integrate attestation via Keylime with the Ironic state machine We have released a new version of Keylime today (v2.3.3) that includes IPsec configuration + documentation, as well as some readme improvements: https://github.com/mit-ll/python-keylime. There is also documentation available in the /doc/ directory as we pointed out earlier (including our ACSAC paper and presentation), and we would be happy to answer any questions you may have. We have also opened up an issue related to integrating Keylime with the Fedora early boot components for easier collaboration, especially if Ali chooses to work on this during the summer: https://github.com/mit-ll/python-keylime/issues/6 Additionally, as we discussed with Peter during the Roundtable, we have opened an issue to investigate adding TPM 2.0 support to Keylime (see https://github.com/mit-ll/python-keylime/issues/5) instead of relying only on the older TPM 1.2. We would like to discuss the future steps towards making Keylime more production-ready so we can complete the goals outlined above, and we are certainly open to supporting this effort from our side as well. We can also set up a telecom if you are interested in discussing this further. Best regards, Charlie ---- Charles Munson, Ph.D. (x9331) Technical Staff charles.munson at ll.mit.edu Secure, Resilient Systems and Technology (5-53) MIT Lincoln Laboratory From: on behalf of Hugh Brock Date: Monday, April 9, 2018 at 5:19 PM To: "rh-moc-bare-metal at redhat.com" Subject: [Rh-moc-bare-metal] Further discussion on bare metal provisioning Folks, As you have probably seen, I have added you to a new mailing list for the purpose of following up on Friday's bare metal provisioning workshop. Please feel free to comment on the summary document Orran and I prepared, here: https://docs.google.com/document/d/1JNmhqCpoG1irj9mb4o46VpISPvN8E7DAICFiT7BwmVk/edit?usp=sharing Thanks for your interest. We'll have further updates forthcoming. Take care, --Hugh -- Hugh Brock, mailto:hbrock at redhat.com Director of Engineering, Boston University Research Initiatives --- "I know that you believe you understand what you think I said, but I'm not sure you realize that what you heard is not what I meant." --Robert McCloskey _______________________________________________ Rh-moc-bare-metal mailing list Rh-moc-bare-metal at redhat.com https://www.redhat.com/mailman/listinfo/rh-moc-bare-metal -- Luke Hinds | NFV Partner Engineering | CTO Office | Red Hat e: lhinds at redhat.com | irc: lhinds @freenode | t: +44 12 52 36 2483 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5215 bytes Desc: not available URL: From lhinds at redhat.com Tue May 8 12:34:13 2018 From: lhinds at redhat.com (Luke Hinds) Date: Tue, 8 May 2018 13:34:13 +0100 Subject: [Rh-moc-bare-metal] Further discussion on bare metal provisioning In-Reply-To: <365B2E88-F66A-46F2-9671-84C2D3B1FE4E@ll.mit.edu> References: <59FBE487-44E2-456C-986F-64EA3B2455DC@ll.mit.edu> <365B2E88-F66A-46F2-9671-84C2D3B1FE4E@ll.mit.edu> Message-ID: Hi Nabil, Thank you for taking the time to get me up to speed, the history definitely helped me get the needed context of where we are. Apologies for late reply, we had a public holiday in the UK yesterday. Hope you don't mind some more questions incoming..Where does keylime stand in respect of containers? Have you done any work with kubenetes? Node trust would be one (kube-scheduler I would guess), but also perhaps more interesting binary integrity and ensuring an application can trust its runtime components within the container? Cheers, Luke On Fri, May 4, 2018 at 9:14 PM, Schear, Nabil - 0553 - MITLL < nabil at ll.mit.edu> wrote: > Luke, > > > > There's quite a lot to discuss in your questions. So, it might make sense > to talk offline about all the details. That said, I'll give some quick > responses: > > > > Keylime only works with the vTPM implementation in Xen. This > implementation was done a few years ago by the government/industry folks > and Xen ingested it more or less as is. Some of the same people, (in this > case IBM), ported the same to qemu and then tried to upstream it. The qemu > folks didn't want to ingest 50K+ lines of code into their project and > therefore own and need to maintain it. So, they said no. Not to be > beaten, IBM then set out on a multiyear effort to create interfaces in qemu > using CUSE (like FUSE for fs, but instead of char devices in userspace). > They then built a new TPM emulator that could speak CUSE. > https://github.com/stefanberger/swtpm So, you could run a bunch of tpm > emulators in your KVM host and then use CUSE to wire them up to individual > vms. I've never tried to set this up, but it appears to exist (if you look > at stefan's other repos, you can see other tools like libvirt that they've > patched up to make this work). I believe it's their hope that they can > upstream this into qemu because the TPM emulator isn't included. I don't > know where that is in the process. The security model for vtpm in KVM in > this way is a good bit different than how it's done in Xen and I think that > Xen's approach is superior. At a high level, there's no reason that both > swtpm and keylime couldn't be ported to work with one another. There's > some additional features that we require that I don't know that they have. > But, not too hard to add. Nothing fundamental. > > > > Now as to timeliness of attestation?Attestation is distinctly a statement > about the past. In the case of a physical TPM, the quote probably at least > half a second old by the time you can give a signed version to someone for > attestation. There are a variety of methods in the literature for dealing > with this that I can talk about offline. Quick take: this is still an > unsolved problem generally. keylime is merely a tool for attesting TPM > state and using it for key agreement. We rely on a completely separate set > of mechanisms (e.g., coreboot, trusted grub, IMA, etc.) for actually > recording integrity measurements into the TPM. Keylime supports repeatedly > asking for attestations from a node. This is so that whatever integrity > measurement mechanism you use to record things can be acted upon quickly. > If you only do boot-time measurements (e.g., by using trustedgrub or > tboot), then all this will net you is the ability to detect if the machine > has been rebooted into an unknown state. If you're using IMA to measure > binaries as they run, then keylime can react to an unknown binary being > executed. If you're doing some super cool thing like LKIM, then keylime > can handle that too. > > > > One last thing: the TCG had a concept for this additional attestation > metadata called OpenPTS. I think strongswan is the only thing out there > that actually uses it. I've heard from others that they're trying to > re-design it to be better. Some of the same folks behind the Xen vTPM > implementation have a proposal for this: https://arxiv.org/abs/1709.10147 > > > > Quick response complete =) > > > > Best, > > -Nabil > > > > -- > > Nabil Schear, Ph.D. > > Senior Staff, Secure Resilient Systems and Technology Group > > MIT Lincoln Laboratory, 244 Wood St, Lexington, MA 02420 > > > Tel: 781-981-5744 Office: C-290F > > *From: * on behalf of Luke Hinds < > lhinds at redhat.com> > *Date: *Friday, May 4, 2018 at 5:53 AMEDT > *To: *"Munson, Charles - 0553 - MITLL" > *Cc: *"rh-moc-bare-metal at redhat.com" > *Subject: *Re: [Rh-moc-bare-metal] Further discussion on bare metal > provisioning > > > > Hi Charlie, > > Had some time to read over the slides `docs/llsrc-keylime-acsac-v6.ppt` > for keylime and have a few questions: > > vTPM , Keylime sits on Xen hypervisor here, what is the state of play with > KVM/QEMU? > > You have the question in slide #3 'Cloud Trust Challenges' - "After I > provision it, how do I know my cloud machine is still good?", but I could > not spot an answer (might be my own misread). > > This was one of the concerns that came up in openstack/nova when TPM was > first positioned. Nodes were designated as 'trusted' based on last boot, > but that boot may have been some time ago and the machine may have been > compromised since then. > > Do you have a proposal on how to address this 'rear view mirror' level of > Trust, that degrades after the last known good boot? > > My own ideas around this have been that Trust should be a weighted factor > somehow, where attributes such as time since last boot are combined with > perhaps post boot factors such as file integrity hashes, os packages are > updated. Then a OP can weight that level of trust themselves for different > workloads and their required privacy level. This is where I favour an open > API approach, so TPM can be a factor in what is 'trust', more than an > complete arbiter. > > Regards, > > Luke > > > > On Mon, Apr 23, 2018 at 11:32 PM, Munson, Charles - 0553 - MITLL < > Charles.Munson at ll.mit.edu> wrote: > > Hello, > > > > We are definitely interested in working towards making Keylime a more > easily supportable attestation infrastructure. As per the notes from the > roundtable discussion we had a few weeks ago, outlined are some goals for > Keylime and attestation: > > > > *Keylime and attestation.* > > *? We believe Keylime could fill a very useful niche upstream, especially > in that the only project that rivals it -- Intel's OpenCIT -- appears to be > open-source in name only and probably not truly open to outside > contributors. We should therefore as a group devote some effort to > packaging Keylime, building a CI infrastructure around it, and generally > making it reasonable to use in a production environment. We should also:* > > *o do the work necessary to integrate it with the Fedora early boot > components;* > > *o consider whether it should find a home with an existing upstream > project like Katello (part of Satellite) or FreeIPA (Red Hat identity > management project);* > > *o Examine -- as a research project? -- how to integrate attestation via > Keylime with the Ironic state machine* > > > > We have released a new version of Keylime today (v2.3.3) that includes > IPsec configuration + documentation, as well as some readme improvements: > https://github.com/mit-ll/python-keylime. There is also documentation > available in the /doc/ directory as we pointed out earlier (including our > ACSAC paper and presentation), and we would be happy to answer any > questions you may have. > > > > We have also opened up an issue related to integrating Keylime with the > Fedora early boot components for easier collaboration, especially if Ali > chooses to work on this during the summer: https://github.com/mit-ll/ > python-keylime/issues/6 > > > > Additionally, as we discussed with Peter during the Roundtable, we have > opened an issue to investigate adding TPM 2.0 support to Keylime (see > https://github.com/mit-ll/python-keylime/issues/5) instead of relying > only on the older TPM 1.2. > > > > We would like to discuss the future steps towards making Keylime more > production-ready so we can complete the goals outlined above, and we are > certainly open to supporting this effort from our side as well. We can > also set up a telecom if you are interested in discussing this further. > > > > Best regards, > > Charlie > > > > ---- > > *Charles Munson, Ph.D.* (*x9331*) > > Technical Staff > > charles.munson at ll.mit.edu > > Secure, Resilient Systems and Technology (5-53) > > MIT Lincoln Laboratory > > > > > > > > From: on behalf of Hugh Brock < > hbrock at redhat.com> > > Date: Monday, April 9, 2018 at 5:19 PM > > To: "rh-moc-bare-metal at redhat.com" > > Subject: [Rh-moc-bare-metal] Further discussion on bare metal provisioning > > > > Folks, > > > > As you have probably seen, I have added you to a new mailing list for the > purpose of following up on Friday's bare metal provisioning workshop. > Please feel free to comment on the summary document Orran and I prepared, > here: > > > > https://docs.google.com/document/d/1JNmhqCpoG1irj9mb4o46VpISPvN8E > 7DAICFiT7BwmVk/edit?usp=sharing > > > > Thanks for your interest. We'll have further updates forthcoming. > > > > Take care, > > --Hugh > > -- > > Hugh Brock, mailto:hbrock at redhat.com > > Director of Engineering, Boston University Research Initiatives > > --- > > "I know that you believe you understand what you think I said, but I'm not > sure you realize that what you heard is not what I meant." --Robert > McCloskey > > > _______________________________________________ > Rh-moc-bare-metal mailing list > Rh-moc-bare-metal at redhat.com > https://www.redhat.com/mailman/listinfo/rh-moc-bare-metal > > > > > -- > > Luke Hinds | NFV Partner Engineering | CTO Office | Red Hat > e: lhinds at redhat.com | irc: lhinds @freenode | t: +44 12 52 36 2483 > -- Luke Hinds | NFV Partner Engineering | CTO Office | Red Hat e: lhinds at redhat.com | irc: lhinds @freenode | t: +44 12 52 36 2483 -------------- next part -------------- An HTML attachment was scrubbed... URL: From nabil at ll.mit.edu Tue May 8 14:15:43 2018 From: nabil at ll.mit.edu (Schear, Nabil - 0553 - MITLL) Date: Tue, 8 May 2018 14:15:43 +0000 Subject: [Rh-moc-bare-metal] Further discussion on bare metal provisioning In-Reply-To: References: <59FBE487-44E2-456C-986F-64EA3B2455DC@ll.mit.edu> <365B2E88-F66A-46F2-9671-84C2D3B1FE4E@ll.mit.edu> Message-ID: <1D45D134-897F-4A6E-82C8-3D8C36308C64@ll.mit.edu> We've not done anything specific with containers and keylime.? That said, it would be straight-forward to use secure boot techniques and keylime to get trusted container hosts. ?Extending that to scheduling metadata the way that openstack did trusted computing pools also seems straight forward. I believe that the coreos folks did this with tectonic.? Now that they are part of the redhat family, it might be good to reach out to see what they have.? They've definitely built some basic but production-ready attestation stuff. On the integrity measurement side of the house, I do not believe that IMA supports cgroups.? So, right now it's not possible to do detailed integrity measurements at the container level.? It would take some kernel hacking and a container-friendly design for measurement list tracking but I don't think there's anything fundamental to doing this, just no one has.? Best, -Nabil -- Nabil Schear, Ph.D. Senior Staff, Secure Resilient Systems and Technology Group MIT Lincoln Laboratory, 244 Wood St, Lexington, MA 02420 Tel: 781-981-5744 Office: C-290F From: Luke Hinds Date: Tuesday, May 8, 2018 at 8:41 AMEDT To: "Schear, Nabil - 0553 - MITLL" Cc: "Munson, Charles - 0553 - MITLL" , "rh-moc-bare-metal at redhat.com" Subject: Re: [Rh-moc-bare-metal] Further discussion on bare metal provisioning Hi Nabil, Thank you for taking the time to get me up to speed, the history definitely helped me get the needed context of where we are. Apologies for late reply, we had a public holiday in the UK yesterday. Hope you don't mind some more questions incoming..Where does keylime stand in respect of containers? Have you done any work with kubenetes? Node trust would be one (kube-scheduler I would guess), but also perhaps more interesting binary integrity and ensuring an application can trust its runtime components within the container? Cheers, Luke On Fri, May 4, 2018 at 9:14 PM, Schear, Nabil - 0553 - MITLL wrote: Luke, There's quite a lot to discuss in your questions. So, it might make sense to talk offline about all the details. That said, I'll give some quick responses: Keylime only works with the vTPM implementation in Xen. This implementation was done a few years ago by the government/industry folks and Xen ingested it more or less as is. Some of the same people, (in this case IBM), ported the same to qemu and then tried to upstream it. The qemu folks didn't want to ingest 50K+ lines of code into their project and therefore own and need to maintain it. So, they said no. Not to be beaten, IBM then set out on a multiyear effort to create interfaces in qemu using CUSE (like FUSE for fs, but instead of char devices in userspace). They then built a new TPM emulator that could speak CUSE. https://github.com/stefanberger/swtpm So, you could run a bunch of tpm emulators in your KVM host and then use CUSE to wire them up to individual vms. I've never tried to set this up, but it appears to exist (if you look at stefan's other repos, you can see other tools like libvirt that they've patched up to make this work). I believe it's their hope that they can upstream this into qemu because the TPM emulator isn't included. I don't know where that is in the process. The security model for vtpm in KVM in this way is a good bit different than how it's done in Xen and I think that Xen's approach is superior. At a high level, there's no reason that both swtpm and keylime couldn't be ported to work with one another. There's some additional features that we require that I don't know that they have. But, not too hard to add. Nothing fundamental. Now as to timeliness of attestation?Attestation is distinctly a statement about the past. In the case of a physical TPM, the quote probably at least half a second old by the time you can give a signed version to someone for attestation. There are a variety of methods in the literature for dealing with this that I can talk about offline. Quick take: this is still an unsolved problem generally. keylime is merely a tool for attesting TPM state and using it for key agreement. We rely on a completely separate set of mechanisms (e.g., coreboot, trusted grub, IMA, etc.) for actually recording integrity measurements into the TPM. Keylime supports repeatedly asking for attestations from a node. This is so that whatever integrity measurement mechanism you use to record things can be acted upon quickly. If you only do boot-time measurements (e.g., by using trustedgrub or tboot), then all this will net you is the ability to detect if the machine has been rebooted into an unknown state. If you're using IMA to measure binaries as they run, then keylime can react to an unknown binary being executed. If you're doing some super cool thing like LKIM, then keylime can handle that too. One last thing: the TCG had a concept for this additional attestation metadata called OpenPTS. I think strongswan is the only thing out there that actually uses it. I've heard from others that they're trying to re-design it to be better. Some of the same folks behind the Xen vTPM implementation have a proposal for this: https://arxiv.org/abs/1709.10147 Quick response complete =) Best, -Nabil -- Nabil Schear, Ph.D. Senior Staff, Secure Resilient Systems and Technology Group MIT Lincoln Laboratory, 244 Wood St, Lexington, MA 02420 Tel: 781-981-5744 Office: C-290F From: on behalf of Luke Hinds Date: Friday, May 4, 2018 at 5:53 AMEDT To: "Munson, Charles - 0553 - MITLL" Cc: "rh-moc-bare-metal at redhat.com" Subject: Re: [Rh-moc-bare-metal] Further discussion on bare metal provisioning Hi Charlie, Had some time to read over the slides `docs/llsrc-keylime-acsac-v6.ppt` for keylime and have a few questions: vTPM , Keylime sits on Xen hypervisor here, what is the state of play with KVM/QEMU? You have the question in slide #3 'Cloud Trust Challenges' - "After I provision it, how do I know my cloud machine is still good?", but I could not spot an answer (might be my own misread). This was one of the concerns that came up in openstack/nova when TPM was first positioned. Nodes were designated as 'trusted' based on last boot, but that boot may have been some time ago and the machine may have been compromised since then. Do you have a proposal on how to address this 'rear view mirror' level of Trust, that degrades after the last known good boot? My own ideas around this have been that Trust should be a weighted factor somehow, where attributes such as time since last boot are combined with perhaps post boot factors such as file integrity hashes, os packages are updated. Then a OP can weight that level of trust themselves for different workloads and their required privacy level. This is where I favour an open API approach, so TPM can be a factor in what is 'trust', more than an complete arbiter. Regards, Luke On Mon, Apr 23, 2018 at 11:32 PM, Munson, Charles - 0553 - MITLL wrote: Hello, We are definitely interested in working towards making Keylime a more easily supportable attestation infrastructure. As per the notes from the roundtable discussion we had a few weeks ago, outlined are some goals for Keylime and attestation: Keylime and attestation. ? We believe Keylime could fill a very useful niche upstream, especially in that the only project that rivals it -- Intel's OpenCIT -- appears to be open-source in name only and probably not truly open to outside contributors. We should therefore as a group devote some effort to packaging Keylime, building a CI infrastructure around it, and generally making it reasonable to use in a production environment. We should also: o do the work necessary to integrate it with the Fedora early boot components; o consider whether it should find a home with an existing upstream project like Katello (part of Satellite) or FreeIPA (Red Hat identity management project); o Examine -- as a research project? -- how to integrate attestation via Keylime with the Ironic state machine We have released a new version of Keylime today (v2.3.3) that includes IPsec configuration + documentation, as well as some readme improvements: https://github.com/mit-ll/python-keylime. There is also documentation available in the /doc/ directory as we pointed out earlier (including our ACSAC paper and presentation), and we would be happy to answer any questions you may have. We have also opened up an issue related to integrating Keylime with the Fedora early boot components for easier collaboration, especially if Ali chooses to work on this during the summer: https://github.com/mit-ll/python-keylime/issues/6 Additionally, as we discussed with Peter during the Roundtable, we have opened an issue to investigate adding TPM 2.0 support to Keylime (see https://github.com/mit-ll/python-keylime/issues/5) instead of relying only on the older TPM 1.2. We would like to discuss the future steps towards making Keylime more production-ready so we can complete the goals outlined above, and we are certainly open to supporting this effort from our side as well. We can also set up a telecom if you are interested in discussing this further. Best regards, Charlie ---- Charles Munson, Ph.D. (x9331) Technical Staff charles.munson at ll.mit.edu Secure, Resilient Systems and Technology (5-53) MIT Lincoln Laboratory From: on behalf of Hugh Brock Date: Monday, April 9, 2018 at 5:19 PM To: "rh-moc-bare-metal at redhat.com" Subject: [Rh-moc-bare-metal] Further discussion on bare metal provisioning Folks, As you have probably seen, I have added you to a new mailing list for the purpose of following up on Friday's bare metal provisioning workshop. Please feel free to comment on the summary document Orran and I prepared, here: https://docs.google.com/document/d/1JNmhqCpoG1irj9mb4o46VpISPvN8E7DAICFiT7BwmVk/edit?usp=sharing Thanks for your interest. We'll have further updates forthcoming. Take care, --Hugh -- Hugh Brock, mailto:hbrock at redhat.com Director of Engineering, Boston University Research Initiatives --- "I know that you believe you understand what you think I said, but I'm not sure you realize that what you heard is not what I meant." --Robert McCloskey _______________________________________________ Rh-moc-bare-metal mailing list Rh-moc-bare-metal at redhat.com https://www.redhat.com/mailman/listinfo/rh-moc-bare-metal -- Luke Hinds | NFV Partner Engineering | CTO Office | Red Hat e: lhinds at redhat.com | irc: lhinds @freenode | t: +44 12 52 36 2483 -- Luke Hinds | NFV Partner Engineering | CTO Office | Red Hat e: lhinds at redhat.com | irc: lhinds @freenode | t: +44 12 52 36 2483 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5215 bytes Desc: not available URL: