gramine-sgx-get-token fails on a read-only rootfs

[mythi]

Description of the problem

Steps to reproduce

It's a common security measure to run containers with their rootfs mounted as read-only. In kubernetes this is enforced in the apps securityContext and some clusters may even enforce security policies to forbid running apps without read-only=true.

With docker this is run as:

$ docker run -it --read-only --device /dev/sgx_enclave -v /dev/sgx:/dev/sgx -v /var/run/aesmd:/var/run/aesmd <GSC'd image>

Expected results

The image runs OK.

Actual results

graphene-sgx-get-token: error: argument --output/-output: can't open '/entrypoint.token': [Errno 30] Read-only file system: '/entrypoint.token'

Notes

This is related to #37 which also talks about making it "pythonless". Could the token be generated by the loader(?) so that it's does not need to be stored on a rootfs?

[dimakuv]

@mythi Thanks for raising this issue!

It's yet another angle of view for the "remove the SGX token" discussion. Actually, we have a long-standing PR to remove the token on DCAP-based systems: gramineproject/gramine#363. We put that PR on hold because we had higher-priority tasks on our plate.

But now it seems like a good time to finally remove the SGX token generation:

• It requires a Python dependency because the SGX-token-generator tool gramine-sgx-get-token is written in Python; it is typically the only tool that requires a Python dependency, which is annoying (need to install Python on an otherwise-slim Docker image).
• As this issue outlines, the SGX token generation conflicts with --read-only FS deployments (typical in Kubernetes).
• On DCAP systems (actually, FLC-enabled systems), the generated SGX token is a "dummy". It is generated purely for compatibility with the flow on EPID systems. This is not a good justification for its existence.

Asking others for their opinion: @mkow @boryspoplawski @oshogbo @woju @aneessahib @veenasai2 Is it time to remove the SGX token from DCAP-based Gramine? For EPID-based, it will stay of course. You can see the proposed implementation in gramineproject/gramine#363.

[mythi]

requires a Python dependency, which is annoying (need to install Python on an otherwise-slim Docker image).

not just annoying but this adds to TCB as well and it's highlighted as one of the "major features" in #13:

"Current implementation increases TCB (trusted files) by required software packages to generate manifest files or sgx-token (including Python), minimize these dependencies "

[dimakuv]

I revived the core Gramine PR to remove the dependency on the SGX Launch Token: gramineproject/gramine#363

I will create another PR in this (GSC) repo to not invoke gramine-sgx-get-token tool at all, but hidden behind a command-line switch to GSC. @mythi Would that work for you?

GSC cannot unconditionally skip gramine-sgx-get-token because it may use an old version of Gramine that doesn't have my proposed fix (gramineproject/gramine#363). So we need to give user a way to switch this off and on. This will default to the old behavior of GSC (creating the token file), but may be overriden to support cases like yours read-only rootfs. In the future, after some deprecation period, we'll switch GSC to default to the new behavior (skipping the token file).

Does that sound good?

[mkow]

GSC cannot unconditionally skip gramine-sgx-get-token because it may use an old version of Gramine that doesn't have my proposed fix (gramineproject/gramine#363).

Wasn't GSC supposed to follow current master, or maybe we've changed this policy and I forgot?

[dimakuv]

Wasn't GSC supposed to follow current master, or maybe we've changed this policy and I forgot?

No, why. GSC can use any compatible version. I think the policy is that GSC must work with the latest stable release (v1.2 currently) and up to the latest master. Supporting e.g. v1.1 is desired but not required.

[dimakuv]

Create a GSC PR too: #62

[mythi]

I will create another PR in this (GSC) repo to not invoke gramine-sgx-get-token tool at all, but hidden behind a command-line
switch to GSC. @mythi Would that work for you?

@dimakuv this works for me, thanks a lot! I'm not clear do I also need gramineproject/gramine#363 or is #62 alone sufficient?

[dimakuv]

@mythi If you want to test it, then you need to do like this, all in the GSC repo:

1. Checkout the branch corresponding to PR Allow to skip SGX token generation #62:

git checkout dimakuv/skip-token-file-generation

3. Open ``config.yaml` and change to the github repo + branch corresponding to PR remove launch token dependency for DCAP enclaves gramine#363:

Gramine:
    Repository: "https://github.com/lead4good/gramine.git"
    Branch:     "remove_dcap_token_dependency"

4. Now rebuild your GSC image using the classic gsc build + gsc sign-image, but don't forget the --skip-token-generation flag:

# I'm using Python image as an example here
./gsc build --skip-token-generation --insecure-args python test/generic.manifest
./gsc sign-image python enclave-key.pem