How to use gramine-sgx container (with gsc) and named pipes?

[YanAlmeida]

Description of the problem

I am using GSC to run a python application in a docker container inside a SGX Enclave. This container should be able to write to a named pipe and read from another, so it can communicate with another proccess.

After building and signing the image, I run:

sudo docker run --device=/dev/sgx_enclave -v /tmp/named_pipes:/tmp/named_pipes gsc-yanalmeida91/sgx-blockchain-pull:latest

If there are no named pipes in /tmp/named_pipes, the application tries to create them. It does not throw any errors, but the command "open(WRITE_NAMED_PIPE_PATH, 'w')" throws an error of invalid arg.

If I create the named pipes beforehand, the command "os.path.exists()" returns False, but when the enclave tries to create it, receives Permission Denied error. If I remove the creation part of the code, I get the same Permission Denied error when trying to open the named pipes (both in read and write mode).

What is happening?

UPDATE: I found out that it's working for regular files. The problem is accessing the named pipes. Why? Is something missing in the manifest?

My manifest file:

loader.env.READ_PIPE_PATH = "/tmp/named_pipes/write_pipe"
loader.env.WRITE_PIPE_PATH = "/tmp/named_pipes/read_pipe"

sgx.allowed_files = ["file:/tmp/named_pipes/write_pipe", "file:/tmp/named_pipes/read_pipe"]

sgx.enclave_size = "4G"
sgx.thread_num = 8

Steps to reproduce

You can try to reproduce it by graminizing my base docker image: yanalmeida91/sgx-blockchain-pull:latest and trying to run it.
I'm graminizing it in virtual machines in azure, running a bootstraping script:

#!/bin/bash
sudo apt-get update
sudo apt-get install -y build-essential ocaml automake autoconf libtool wget python3 python3-pip libssl-dev dkms
sudo update-alternatives --install /usr/bin/python python /usr/bin/python3 1
sudo wget https://download.01.org/intel-sgx/latest/dcap-latest/linux/distro/${var.sgx_driver_distro_name}/${var.sgx_driver_file_name}
sudo chmod 777 ${var.sgx_driver_file_name}
sudo ./${var.sgx_driver_file_name}
sudo apt-get install -y docker.io

sudo apt-get install git
sudo pip3 install docker jinja2 tomli tomli-w pyyaml

sudo docker pull ${var.dockerhub_image_sgx}
sudo docker pull ${var.dockerhub_image_sgx_untrusted}

git clone https://github.com/YanAlmeida/gsc-v1.5-adjustment.git
sudo chmod -R 777 /gsc-v1.5-adjustment
cd gsc-v1.5-adjustment

cp config.yaml.template config.yaml
echo "${file("./tee_machine_config/enclave-key.pem")}" > enclave-key.pem

echo "${file("./manifest.txt")}" >> config.manifest

sudo ./gsc build --insecure-args ${var.dockerhub_image_sgx} test/generic.manifest
sudo ./gsc sign-image ${var.dockerhub_image_sgx} enclave-key.pem

sudo rm enclave-key.pem

sudo docker run -d --device=/dev/sgx_enclave  -v /var/run/aesmd/aesm.socket:/var/run/aesmd/aesm.socket -v /tmp/named_pipes:/tmp/named_pipes gsc-${var.dockerhub_image_sgx}

Expected results

Named pipes created and working with the enclave

Actual results

Errors or named pipes created but not appearing on host folder via docker volume

[dimakuv]

Named pipes between a Gramine process and a non-Gramine process are impossible.

This is due to security reasons. Pipes are inter-process communication primitives. Named pipes are just pipes that have an associated inode (file on the file system).

Pipes are transparently encrypted by Gramine. So named pipes are also transparently encrypted by Gramine. The encryption key is generated inside Gramine processes (enclaves) and is securely shared among Gramine processes.

Clearly, a non-Gramine process cannot participate in such inter-Gramine communication. That would mean either (1) the pipes would not be encrypted by Gramine, and all data would be in plaintext and not protected, or (2) the non-Gramine process would get access to the encryption key, which would imply that an untrusted host gets access to the encryption key and destroys all security guarantees of Gramine.

Therefore, Gramine opts for an obvious choice: pipe communication between Gramine and non-Gramine processes is disallowed.

[YanAlmeida]

Hi, Dmitri, thanks for answering!

My project consists in processing data from Ethereum using SGX for security reasons. My idea was to keep data encrypted "end-to-end". It means that the encryption keys would be stored and shared with the enclave and the final user in a safe manner and that encryption would be asymmetric, which is out of the scope of my project.

This way, I drew an architecture in which a regular process interacts with the internet, fetches data, polls ethereum etc., and the TEE process only receives data. My idea was to keep the Gramine-SGX container small (avoiding performance issues) and isolated from any network connection (reducing, this way, the attack surface, I imagine?).
Does it make any sense? Would it be a better/safer option to make the Gramine-SGX container communicate directly to the internet and have the whole application logic?

To communicate both process, now I'm using TCP Sockets, which are allowed. This way, it's now working, but I got concerned about the best practice in my scenario.

Thanks in advance!

[dimakuv]

To communicate both process, now I'm using TCP Sockets, which are allowed. This way, it's now working, but I got concerned about the best practice in my scenario.

Yes, this is the best practice for such cases as yours. Don't forget to apply TLS on top of your TCP connections (i.e., to protect sessions with a well-known encryption scheme). Alternatively, use your own crypto -- that's how I understood what you're doing -- but be aware that rolling out your own crypto protocols is very much discouraged in the security community (you won't get it right from the first try).

Does it make any sense? Would it be a better/safer option to make the Gramine-SGX container communicate directly to the internet and have the whole application logic?

In my opinion, that would be better and easier to program. I still don't understand how you keep the data encrypted "end-to-end", given that you have a "proxy" untrusted process...