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

Tue May 8 14:15:43 UTC 2018

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 <lhinds at redhat.com>
Date: Tuesday, May 8, 2018 at 8:41 AMEDT
To: "Schear, Nabil - 0553 - MITLL" <nabil at ll.mit.edu>
Cc: "Munson, Charles - 0553 - MITLL" <Charles.Munson at ll.mit.edu>, "rh-moc-bare-metal at redhat.com" <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 <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: <rh-moc-bare-metal-bounces at redhat.com> on behalf of Luke Hinds <lhinds at redhat.com>
Date: Friday, May 4, 2018 at 5:53 AMEDT
To: "Munson, Charles - 0553 - MITLL" <Charles.Munson at ll.mit.edu>
Cc: "rh-moc-bare-metal at redhat.com" <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: <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/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: <http://listman.redhat.com/archives/rh-moc-bare-metal/attachments/20180508/2a4176ed/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5215 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/rh-moc-bare-metal/attachments/20180508/2a4176ed/attachment.p7s>