Future direction of Graphene Shielded Containers

[vahldiek]

Description of the problem

The first version of Graphene Shielded Containers (PR gramineproject/graphene#1430) is limited in scope and we've frozen the feature list. This issue lists limitations and possible future features, and should serve as a discussion forum for others to highlight which features are a priority.

Security issues:

• Graphene is not production ready. See issue Known issues for production deployment gramine#7 for details on production blockers
• GSC only uses insecure command line arguments specified via Docker run when specifying --insecure-args during build.
• GSC uses insecure environment variables.

Minor features:

• Detect scripts as entrypoints and correctly change the entrypoint to the script interpreter (see issue GSC error with Docker containers using scripts as entrypoints  graphene#1728)
• Provide flag to switch off overestimation to allow more security conscious application of GSC
• Support RPM-based distributions (different dependencies & yum instead of apt)
• Support for additional Docker build arguments such as build_args or network_mode in the configuration file
• Support local SGX driver header files instead of header files from repository
• Support to supply the signing key in the configuration, use it for signing and then destroy
• Support rebuild of image without cached entries via docker build parameter
docker_api.build(path='gsc-' + image, tag=gsc_image_name(image), nocache=True)
• Support different driver structures such as DCAP
• Split gsc build into two commands, gsc build-graphene and gsc build.
  • gsc build-graphene is the first stage of current gsc build building a Graphene runtime Docker image. This is independent of the application image and can be generalized and does not require to be rebuild for every image.
  • gsc build depends on the previous command gsc build-graphene and copies the runtime over to the application image.
  • Publish the result of gsc build-graphene on dockerhub for supported Distributions (e.g. graphene:ubuntu18.04-sgx1.9)
• Change test Docker image repositories to public repositories such as python or nginx

Major features:

• List of trusted files does not include files in folders of symlinks
  • Implement os.walk in finalize_manifests.py to follow symbolic links while avoiding cyclic dependencies
• Support secret provisioning and use of protected files
  • For EPID and DCAP with toy Graphene secret provisioning
  • For MAA and Azure Key Vault
• Encrypted Docker Images
  • Translate each file in the Docker image to a protected files within the image
  • Support encrypted volumes
  • Translate part of the application image to protected files
• Support m local storage
• Support for non-ASCII characters in filenames of trusted files (mostly issue in Graphene manifest handling)
• Current implementation increases TCB (trusted files) by required software packages to generate manifest files or sgx-token (including Python), minimize these dependencies
• Provide new GSC command which generates MREnclave based on given Docker image (no translation, but generation of MRenclave)

[dimakuv]

Some thoughts on this list, coming from January 2021 (after GSC rework):

GSC uses insecure environment variables

This is not even true. GSC doesn't do anything about environment variables (which is a bug). in Graphene, there must be one of the following manifest options: loader.insecure__use_host_env = 1 or loader.env.[ENVIRON] = "[VALUE]" / loader.env_src_file = "file:file_with_serialized_envs" (see https://graphene.readthedocs.io/en/latest/manifest-syntax.html#environment-variables). However, none of these options are specified in the GSC template manifest, check https://github.com/oscarlab/graphene/blob/master/Tools/gsc/templates/entrypoint.manifest.template.

This means that the final Graphenized Docker image created by GSC has no environment variables other than hard-coded LD_LIBRARY_PATH and PATH. So, currently this part is completely broken in GSC. We need to implement the above options, similar to how command-line arguments are treated (see https://graphene.readthedocs.io/en/latest/manifest-syntax.html#command-line-arguments). In particular, secure ENV variables should be extracted via inspecting the original Docker image.

Refactor tests

GSC has a test/ subdir. It uses a Makefile that got really ugly and convoluted over the years: https://github.com/oscarlab/graphene/blob/master/Tools/gsc/test/Makefile. I suggest to remove this Makefile (and maybe also https://github.com/oscarlab/graphene/blob/master/Tools/gsc/Makefile) and instead do the same with a simple Python/bash script.

[dimakuv]

gramineproject/graphene#2195 -- secure environment variables were added to GSC.

[pravinrajr9]

Does GSC support remote attestation? Can we convert gramine shielded container images to oci compliant and run using cri-o/containerd apart from docker?

[dimakuv]

Does GSC support remote attestation?

Yes, you can look at this pending PR on how it can be done: #11. At some point, we'll merge this PR as an example in GSC.

Can we convert gramine shielded container images to oci compliant and run using cri-o/containerd apart from docker?

There is no such tooling in GSC currently. Note that GSC itself creates a normal Docker image. So if there are some tools to make normal Docker images OCI compliant, then one can use such tools. (I'll be honest, I don't know much about the exact details of what "OCI compliant" means, so I may be wrong in my comment.)

[mythi]

and run using cri-o/containerd apart from docker?

FWIW, I've run GSC images using both runc and kata-runtime in k8s using containerd CRI.

[pravinrajr9]

Thats awesome, thanks

[pravinrajr9]

Is there a way, where can we use container images based out of image other than ubuntu as base image. I see limitation mentioned over here https://gramine.readthedocs.io/projects/gsc/en/latest/#dependency-on-ubuntu
Here it says "GSC can simply be extended to support other distributions by providing a template for this distribution in templates/" Is there any example for this.

[dimakuv]

You can check this work in progress, for CentOS/RHEL support: #43

[dimakuv]

UPDATE:

Detect scripts as entrypoints and correctly change the entrypoint to the script interpreter

This was fixed some time ago with gramineproject/gramine#722, and is available in Gramine v1.3.