8000 stage0: re-evaluate tpm.Extend in critical path · Issue #1816 · rkt/rkt · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content
This repository was archived by the owner on Feb 24, 2020. It is now read-only.

stage0: re-evaluate tpm.Extend in critical path #1816

Closed
jonboulle opened this issue Dec 1, 2015 · 9 comments
Closed

stage0: re-evaluate tpm.Extend in critical path #1816

jonboulle opened this issue Dec 1, 2015 · 9 comments
Labels
area/security component/stage0 help wanted kind/cleanup priority/P1
8000
Milestone
v1.0.0

Comments

@jonboulle
Copy link
Contributor

Capturing discussion in #1775 (diff) : I raised the concern that the tpm.Extend operation is happening during the critical path of container instantiation.

Currently we just try to log in the TPM in every case (irrespective of whether rkt is built with/without TPM support, and whether there happens to be a local TSPI service running), and ignore any error returned by the operation. However, this involves an HTTP request which could fail in arbitrary ways, and potentially time out, etc.

We should deal with this more thoughtfully, especially as we consider adding TPM support to the default build. This will also set us up to deal with the eventual future where we will want to fail hard if the TPM operation does not succeed.
@jonboulle jonboulle added this to the v0.14.0 milestone Dec 1, 2015
@jonboulle jonboulle mentioned this issue Dec 1, 2015
Merged
@alban alban modified the milestones: v0.16.0, v0.15.0 Jan 7, 2016
@iaguis
Copy link
Member
iaguis commented Jan 19, 2016

If I listen to the tpmd port I can block the execution of subsequent rkt runs:

$ sudo rkt run coreos.com/etcd:v2.0.10
rkt: using image from local store for image name coreos.com/rkt/stage1-coreos:0.15.0+git2776960
rkt: using image from local store for image name coreos.com/etcd:v2.0.10

[stays there...]

This is unfortunate because it's an unprivileged port:

$ nc localhost -l -p 12041
POST /v1/extend HTTP/1.1
Host: localhost:12041
User-Agent: Go-http-client/1.1
Content-Length: 799
Content-Type: application/json
Accept-Encoding: gzip

{"Pcr":15,"Eventtype":4096,"Data":null,"Event":"rkt: Rootfs: sha512-bd90da08a4dccea41d0a8258b213b86e3ec98c28f1cd6425e34aad42ad3ad53d Manifest: {\"acVersion\":\"0.15.0+git2776960\",\"acKind\":\"PodManifest\",\"apps\":[{\"name\":\"etcd\",\"image\":{\"name\":\"coreos.com/etcd\",\"id\":\"sha512-c03b055d02e51e36f44a2be436eb77d5b0fbbbe37c00851188d8798912e8508a\",\"labels\":[{\"name\":\"os\",\"value\":\"linux\"},{\"name\":\"arch\",\"value\":\"amd64\"},{\"name\":\"version\",\"value\":\"v2.0.10\"}]},\"app\":{\"exec\":[\"/etcd\"],\"user\":\"0\",\"group\":\"0\"}}],\"volumes\":null,\"isolators\":null,\"annotations\":null,\"ports\":[]} Stage 1 args: /var/lib/rkt/pods/run/44d625f5-f524-4023-9868-f13221bd1036/stage1/rootfs/init --net=default --local-config=/etc/rkt 44d625f5-f524-4023-9868-f13221bd1036"}

@iaguis iaguis mentioned this issue Jan 19, 2016
Merged
@jonboulle
Copy link
Contributor Author

Ick. Maybe for now we should set a connection timeout and fail hard?

@alban alban mentioned this issue Jan 19, 2016
Open
@alban
Copy link
Member
alban commented Jan 19, 2016

The solution could be to get tpmd to listen on a privileged port. See google/go-tspi#3

@jonboulle
Copy link
Contributor Author

We still need to deal with unexpected/bad services listening on that port..

On Tue, Jan 19, 2016 at 8:42 PM, Alban Crequy notifications@github.com
wrote:

The solution could be to get tpmd to listen on a privileged port. See
google/go-tspi#3 google/go-tspi#3

—
Reply to this email directly or view it on GitHub
#1816 (comment).

@iaguis
Copy link
Member
iaguis commented Jan 21, 2016

Let's continue discussing this for 1.0.

@iaguis iaguis modified the milestones: v1.0.0, v0.16.0 Jan 21, 2016
@iaguis
Copy link
Member
iaguis commented Jan 26, 2016

So we could fix this if tpmd listens on a privileged port and we implement some kind of timeout, right?

@jonboulle
Copy link
Contributor Author

I would like to see the timeout for 1.0.

iaguis added a commit to kinvolk-archives/go-tspi that referenced this issue Feb 1, 2016
@iaguis
tpmclient: add timeout
839c88f 
When we send requests to tpmd, we could potentially block for a long
time if an unexpected service is listening on that port.

Allow setting a timeout so users of the library can limit this
possibility.

See rkt/rkt#1816 (comment)
@iaguis iaguis mentioned this issue Feb 1, 2016
Merged
@iaguis
Copy link
Member
iaguis commented Feb 1, 2016

google/go-tspi#4

@iaguis
Copy link
Member
iaguis commented Feb 1, 2016

I would like to see the timeout for 1.0.

We still need to decide whether to enable TPM on the release binary.

iaguis added a commit to kinvolk-archives/go-tspi that referenced this issue Feb 1, 2016
@iaguis
tpmclient: add timeout
368c1fe 
When we send requests to tpmd, we could potentially block for a long
time if an unexpected service is listening on that port.

Allow setting a timeout so users of the library can limit this
possibility.

See rkt/rkt#1816 (comment)
@iaguis iaguis mentioned this issue Feb 1, 2016
Merged
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
area/security component/stage0 help wanted kind/cleanup priority/P1
Projects
None yet
Milestone
v1.0.0
Development

No branches or pull requests
3 participants
@al 2DC2 ban @iaguis @jonboulle
0