Processes with RA-TLS spawning child processes

[tiagorvmartins]

Hello Gramine team, we are currently facing some questions on what would be the best approach for our use case.

We need to include RA-TLS on several components of an existing application, our initial idea was changing/forking each component of this larger application in order to include RA-TLS and then communications between these would be attested through Remote Attestation, this implies each component would live inside it's own enclave.

The problem arised when we bumped into a specific component that relies on closed source code and can't be forked in a way to include RA-TLS.
Another problem of this approach is every time there is an update to these components we need to maintain and support our RA-TLS changes on those forks.

We thought about another potential solution for our use-case but we would really appreciate some feedback on the viability and security concerns of the approach, before moving forward.

Potential Solution would be:

• We would build an application that just serves as proxy for each main component of the larger application
• The proxy application would be constructed in a way that is reusable for all components requiring RA-TLS
• Every component docker image would contain the executable proxy inside and the executable application service, the entrypoint would either be a shell script that spins up both proxy and the component service or the proxy itself could spawn the component service as child process. This docker image would then be graminised.
• Each component's enclave would boot from this proxy application which would spawn as child process the real component application
• RA-TLS between components would in practice be made on the proxy application itself, but since each enclave contains both the proxy and component, the attestation between components would proove that the component executable wasn't modified and it's running inside, an external party could verify this with reproducible builds.

Our questions and concerns:

• Does the server being hosted on child process would be visible to the host or only the main proxy process running inside the enclave?
  Our concern here is that the real component shouldn't be reached from the host but instead the only way to interact with it would be through proxy component.

In case there is any other option or solution please also let us know,
Thank you!

[dimakuv]

Hello Tiago!

Yes, your solution makes sense.

One thing I'm not clear about is when do you want to invoke RA-TLS? Is it only at the start of the application? Or is RA-TLS supposed to be periodically invoked during the lifetime of the application?

If it's only at the start of the application, then the traditional approach (typically called "pre-main") is to:

1. Make what you call a "proxy" the entrypoint for Gramine (and thus for the Docker container).
2. The proxy invokes RA-TLS to prove it's running inside the enclave to other parties. The proxy also creates some "token" or "evidence" that it will pass to the actual application as a proof of SGX-goodness (this "token" is presented by the application to other parties when the app establishes connections with those parties). Typically the "token" is a private-public keypair (so only the application knows the private key that the proxy generated for it), or a classic X.509 certificate (again, the private key of the certificate is only known to the application).
3. At the end of this remote attestation, the proxy puts the "token"/"evidence"/"private key" in e.g. a special environment variable or as a command-line argument and invokes execve(<actual-app>, args, envvars) system call to start the actual application.

This is basically what a special Gramine tool does: https://gramine.readthedocs.io/en/stable/manpages/gramine-ratls.html. Maybe you can just use this tool?

the entrypoint would either be a shell script that spins up both proxy and the component service or the proxy itself could spawn the component service as child process

Yes, both these approaches work. The shell script approach has an advantage that the proxy process doesn't "disappear" after the startup (in contrast to the approach outlined above), but has a disadvantage that you'll have three SGX enclaves now: one for the shell, one for the proxy, and one for the application. In case of execve(), you would only ever have one SGX enclave.

RA-TLS between components would in practice be made on the proxy application itself, but since each enclave contains both the proxy and component, the attestation between components would proove that the component executable wasn't modified and it's running inside, an external party could verify this with reproducible builds.

Yes, correct. You're basically having an indirect chain of trust now: SGX remote attestation proves the correctness of the proxy, and by trusting the proxy code/developers, you gain trust in that it correctly starts up the desired application.

Does the server being hosted on child process would be visible to the host or only the main proxy process running inside the enclave?

I'm not sure what you mean exactly by "visible to the host". If you mean network connections and open ports -- yes, the application (the server) will be visible to the host. Similarly, the files on which the application (the server) operates will be visible on the host.

[tiagorvmartins]

Thank you @dimakuv and Gramine team,
That would be really helpful!!

In case this is eventually implemented, let us know, if possible in this discussion, so we can keep track of it and apply those changes on our side and do our testing. Anyway, we will also be taking close attention to new tags here on gramine github.

In case, there are guidelines for proposal requests (github issues or somewhere) that we should follow, let us know thank you, so we add our bits to it.

Thank you!

[dimakuv]

In case this is eventually implemented, let us know [...]

Well, my problem is that I don't know what you need from Gramine :)

[tiagorvmartins]

Sorry, missunderstood your message,
I am not sure this is even possible from Gramine side, because it might dependant on which library the application uses for ssl, like openssl / mbedtls, etc.

But assuming it is, our feature request would be based on the following:

• unmodified application hosts an https using cert and key from path (this is big win from gramine-ratls wrapper already)
• gramine somehow would intercept all ssl attempts to handshake (would intercepting "mbedtls_ssl_handshake" from the mbedtls_gramine library even work?) then get the certificate from peer connecting, and do ra_tls_verify_callback_extended_der, using the supplied expected_mrenclave and expected_mrsigner as environment variable.

With this we would be covering the following requirements:

• We can boot any application that hosts an https server
• That server uses Gramine self-signed certificates
• That server also verifies that the incoming connections come from specific enclave
• This would be agnostic in a way that no changes are expected in the app being launched (the one that serves the https server)

In summary this would be what we need for this use case.

But I am almost certain that this is not possible to achieve, because its tied to the application itself - how that application functions on a ssl level, meaning: how the application's ssl library is used [ this would require your confirmation ]

Thank you @dimakuv

[mkow]

I am not sure this is even possible from Gramine side, because it might dependant on which library the application uses for ssl, like openssl / mbedtls, etc.

I think what @dimakuv meant was that you can patch Gramine yourself to customize it for your specific app. I don't think it's possible / reasonable to create a flexible interface for doing that on our side which would support all the usecases.

[dimakuv]

gramine somehow would intercept all ssl attempts to handshake (would intercepting "mbedtls_ssl_handshake" from the mbedtls_gramine library even work?) then get the certificate from peer connecting, and do ra_tls_verify_callback_extended_der, using the supplied expected_mrenclave and expected_mrsigner as environment variable.

Yes, this is not possible. SSL/TLS is above the network layer (TCP) which Gramine knows and cares about. So there's nothing Gramine can do about operations at the SSL/TLS layer.

I actually meant is that if you want e.g. a manifest option to disable certain TCP/UDP ports, this feature we could look into.