Two questions: protected_files and enclave key at runtime about gsc HOT 9 CLOSED

On the other hand, if I use instead sgx.trusted_files = [ "file:/resources/" ], then I have a permission issues when trying to write in this directory.

Trusted Files are read-only hashed files. They are not encrypted. This type of files is used purely for things like config files, shared libraries, executables -- things that are set in stone and do not change during Gramine execution.

I've also tried, without success, with: fs.mounts = [ { type = "encrypted", path = "/resources", uri = "/resources", key_name = "file_key" }, ]

This is actually one of the good ways to do it. This will actually force Gramine to encrypt all files created under /resources. It is important that the encryption key (what you specified under "file_key" name) exists prior to creation of any files under this directory. For this, you should use some kind of Secret Provisioning, and yes, we provide a reference library that you can use. You will need to analyze how it works and experiment a bit, starting with https://github.com/gramineproject/gramine/tree/master/CI-Examples/ra-tls-secret-prov.

Also, maybe @aneessahib and @anjalirai-intel can point you to more resources/demos.

By the way, the other thing you can try (if you do not want to persist the files on hard disk) is to use the tmpfs mount point: https://gramine.readthedocs.io/en/latest/manifest-syntax.html#root-fs-mount-point. Files created under the type = "tmpfs" mount are created and accessed purely inside the SGX enclave memory, and thus protected by the SGX hardware itself.

Can I retrieve somehow (from within the enclave) a private/public key pair that is only known by the enclave ?

For encryption of Encrypted Files? Yes, there are two special key names: _sgx_mrenclave and _sgx_mrsigner. Please check https://gramine.readthedocs.io/en/latest/manifest-syntax.html#encrypted-files

Also when I setup an env variable SECRET_PROVISION_CONSTRUCTOR=1, nothing happens.

You need to add more than this. Please check these resources carefully:

• https://gramine.readthedocs.io/en/latest/attestation.html#high-level-secret-provisioning-interface
• https://github.com/gramineproject/gramine/tree/master/CI-Examples/ra-tls-secret-prov

from gsc.

Hi @dimakuv

I've read the example,
but it is still not clear whether I need to go through the complications explains in https://github.com/gramineproject/gramine/tree/master/CI-Examples/ra-tls-secret-prov
in the was where I want to use an eclaved based key.

Or could I simply use
fs.mounts = [ { type = "encrypted", path = "/resources", uri = "/resources", key_name = "_sgx_mrsigner" }, ]
?

I don't really have a secret provisioning server and don't intend to have one in close future,
so having the ability to use a predefined key would make my life much easier.

Also, where/how could I retrieve this key for other purposes than file encryption ?

Thanks in advance,
Loic

from gsc.

Or could I simply use `fs.mounts = [ { type = "encrypted", path = "/resources", uri = "/resources", key_name = "_sgx_mrsigner" }, ] ?

Yes, you can. But only for gramine-sgx, not for gramine-direct (for the obvious reason that the latter doesn't use SGX hardware).

Also, where/how could I retrieve this key for other purposes than file encryption ?

Yes, inside Gramine environment, a special file is created: /dev/attestation/keys/<key_name>. Please check https://gramine.readthedocs.io/en/latest/attestation.html (search for key_name on the page).

So when you're using gramine-sgx, there should be a file called /dev/attestation/keys/_sgx_mrsigner.

from gsc.

Ok, I tried...

I am using a gsc fied container built with the following manifest:

loader.pal_internal_mem_size = "256M"
loader.insecure__use_host_env = true
libos.check_invalid_pointers = false
loader.env.KMP_AFFINITY = "granularity=fine,noverbose,compact,1,0"
sgx.remote_attestation = "dcap"
sgx.enclave_size = "1G"
sgx.preheat_enclave = true
sgx.thread_num = 8

#sgx.allowed_files = [ "file:/resources/" ]   ### REMARK, IF I USE THIS INSTEAD OF FS.MOUNTS IT WORKS

fs.mounts = [
  { type = "encrypted", path = "/resources", uri = "/resources", key_name = "_sgx_mrsigner" },
]

when I execute it, It fails with the following log+error:

Gramine is starting. Parsing TOML manifest file, this may take some time...
Detected a huge manifest, preallocating 64MB of internal memory.
-----------------------------------------------------------------------------------------------------------------------
Gramine detected the following insecure configurations:

  - loader.insecure__use_cmdline_argv = true   (forwarding command-line args from untrusted host to the app)
  - loader.insecure__use_host_env = true       (forwarding environment vars from untrusted host to the app)

Gramine will continue application execution, but this configuration must not be used in production!
-----------------------------------------------------------------------------------------------------------------------

[P1:T1:] error: error mounting "/resources" (encrypted) under /resources: -22
[P1:T1:] error: Error during libos_init() in init_mount (-22)

Any Idea?
Anything special, I should do because I am using gsc instead of a bare gramine-sgx ?

from gsc.

I may have misunderstood what you want exactly. I was expecting that you will create the /resources-corresponding directory on the host, that will store the encrypted files, and you'll mount it like this:

docker run --volume=<your-empty-dir-on-host>:/resources:rw ...

[P1:T1:] error: error mounting "/resources" (encrypted) under /resources: -22

This error happens because there is no /resources directory inside the (GSC-fied) Docker container that you're running. See my suggestion above how to make this directory visible to the Docker container.

UPDATE: I never used anonymous Docker volumes, but this seems also helpful if you don't need to share the encrypted files with the host. Smth like this should create an anonymous volume:

docker run --volume=/resources:rw ...

from gsc.

Hi @dimakuv ,

I am running on kubernetes, so I can't simply run that command,
but for sure my volume is properly mounted on the host and is accessible.
How do I know? because when I mount the volume with sgx.allowed_files = [ "file:/resources/" ], it works like a charm and my data are preserved on disk even if I remove and restart my kubernetes pod running the gsc container.

So the cause of the error must be somewhere else I fear....
but I have no idea where it could be.

Loic

from gsc.

because when I mount the volume with sgx.allowed_files = [ "file:/resources/" ], it works like a charm and my data are preserved on disk

This is slightly different. sgx.allowed_files does not check on startup whether the directory /resources exists or not. And I assume that your application does an equivalent of mkdir -p /resources and then starts creating files in it.

On the other hand, fs.mounts = [ {"encrypted"} ] checks on startup whether the directory exists or not (actually, I'm not even sure why Gramine does it, or maybe it's a bug).

So this observation doesn't prove to us that Kubernetes deployment actually mounts any volume. If you didn't specify this /resources volume explicitly in the Kubernetes deployment file (I guess in some YAML config), then I would expect that your containers do not have this directory mounted at all.

from gsc.

Hi @dimakuv

I do specify and mount the volume /resources in my kubernetes config.
It is NOT my application that creates it.

As I said previously, my application store files in this directory, and I am sure that the volume connected through kubernetes/docker/gsc and whatever other actor in the chain is properly working, because I can see that my files are preserved when I wipeout everything and recreate everything using sgx.allowed_files.

Why fs.mounts reports and error is beyond my control (and understanding) but it's certainly not because the directory does not exists on the host.

Any suggestion to debug what is going on here ?

Loic

from gsc.

@quertenmont: Please don't use GitHub issues for general support (see the information in the issue template), we use issues to keep track of bugs in Gramine. If you need support then either:

• use GitHub Discussions,
• ask on our Gitter (https://gitter.im/gramineproject/community),
• or send an email to [email protected].

from gsc.