Kill switch for gramine container

[nolasconapoleao]

Hi, I'm working on a project that uses Gramine to wrap around applications and provide confidential computing.
Applications vary in terms of

• programming language GoLang, C++, Bash, Python, Java, ...
• Open vs closed source code
• Initialization entrypoint, ie. bash script or executable

I have a requirement where the graminized container should only run if a condition is successful eg. the time of execution is bellow x seconds. As I see it there are two ways to implement this requirement I can

• adapt the code to wrap execution inside a "keep-alive" mechanism: ie. all apps are spawned from this mechanism and terminated if the condition fails. This is very maintenance intensive and does not work if children processes detach from the the execution (as is the case for exec or command & type calls).

• propagate the equivalent to "Host injected malicious signal" from a thread inside the container, ie. when initializing the container I can start a program that waits 1 minute and terminates the container.

package main

import (
	"fmt"
	"syscall"
	"time"
)

func main() {
	// Set up a timer to send SIGTERM to the command after 1 minute
	fmt.Println("Waiting for 1 minute before sending SIGTERM to the process.")
	time.Sleep(1 * time.Minute)

        // FIXME: What signal should I send?
	fmt.Println("Timer expired. Sending SIGTERM to the process.")
	syscall.Kill(syscall.Getpid(), syscall.SIGTERM)
}

My question is if I can leverage any kill signal for this use case?

Thank you in advance

[dimakuv]

I have a requirement where the graminized container should only run if a condition is successful eg. the time of execution is bellow x seconds.

The example that you showed sends a termination signal to the program (to itself actually) after 1 minute. So what you really want is not a generic "if condition is successful", but just execution with a timeout?

You may want to do smth like this: https://stackoverflow.com/questions/687948/how-to-run-a-command-with-a-timeout-so-that-it-is-killed-if-it-exceeds-the-timeo

Where the "program to execute" is your gramine-sgx ... invocation. So the entrypoint to your Docker container becomes this bash/timeout script, and it invokes gramine-sgx.

[nolasconapoleao]

I'm going for something more generic, like for example

• is this dependency available (http endpoint returns 200)
• is some storage path available (stat /some/file/path).

The problem I'm grappling with is that in some scenarios my entry-point runs multiple processes and some get sent to background, consider this for an example:

#!/bin/bash

# Start the server and is ran in background
/server/server &

# Start the queue processor
/queue/listener

In that case or if I'm working with threads for a database for example, terminating the entrypoint with sigterm may not work since the children processes have taken a life of their own.

My bad forgot to mention that I'm using gsc and not calling gramine-sgx directly.

[nolasconapoleao]

Had a better read on the timeout you sent, the timeout script can be adapted to support my use case.

Alternatively it brought me to this, it explains children background processes can be easily terminated using bash magic.
Not sure how it handles forks and detached processes, but it's a fair assumption that children still attached are the important part to monitor.

Feel free to close the discussion, thank you for the attention.

[mkow]

I'm not sure how exactly you're running this, but a caveat: if you are sending the signal from outside of Gramine, then the termination is outside of the TEE - it means, that a malicious host can just silently skip sending the signal and make your enclave run longer. Whether this is ok depends on your security model.

[nolasconapoleao]

Yes the solution will avoid trust in a host.
It goes something like this, the container pings a "trusted" external endpoint to check if it should keep running.
If there is no response or the condition for keeping alive fails, the pod terminates.

[dimakuv]

My question is if I can leverage any kill signal for this use case?

Yes, by the way, Gramine only reacts to the SIGTERM signal. This is done for security reasons (no other signals can be propagates from the outside world into Gramine).

[nolasconapoleao]

Hey @dimakuv, nice talking to you

That's what I'm looking for, lemme probe a bit more.
I'm actually using gsc with an entrypoint in shell or golang.
"no other signal can propagate from the host to the container" but what about a signal that starts inside the container?
The plan is to have multiple processes running in parallel inside my container and once I send a kill signal, I would like all processes to be terminated to avoid data corruption or improper program calls. The whole ecosystem of processes should terminate "gracefully".

For example if I make my example script output SIGINT can I stop the gsc container from executing more logic?
From your response this is a design decision, which is perfect but is it a good idea to use SIGINT, will this change in the future and make the use case misbehave?

[dimakuv]

"no other signal can propagate from the host to the container" but what about a signal that starts inside the container?

Yes, signals that originate inside the "Gramine ecosystem" should propagate to all Gramine processes in that "ecosystem". However, your scenario sounds rather complex, and I'm not sure if Gramine would support it.

For these signals that originate inside Gramine processes, there is no restriction on the signal number. You can use SIGINT. But as said, I actually doubt it will work correctly, as this case may be too much for Gramine internal logic...