[Rh-moc-bare-metal] Further discussion on bare metal provisioning

Fri May 4 10:52:25 UTC 2018

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 <lhinds at redhat.com> 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: <rh-moc-bare-metal-bounces at redhat.com> 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" <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: <http://listman.redhat.com/archives/rh-moc-bare-metal/attachments/20180504/de60096b/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tci-acm.pdf
Type: application/pdf
Size: 496138 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/rh-moc-bare-metal/attachments/20180504/de60096b/attachment.pdf>