Run command as specific user in gsc

[tomolenet]

Description of the problem

We try to run a command as a specific user inside a graphene container. We do not want the root user to execute our commands.

Steps to reproduce

Follow the instructions of the Graphene Shielded Containers.

In Step 3 do not use the prebuild python image. Use a custom Dockerfile with a custom user.

FROM ubuntu:18.04

RUN apt-get update \
    && apt-get install -y python3 \

RUN useradd example

# Use a custom user
USER example

RUN mkdir -p /graphene/Examples

COPY python/ /graphene/Examples

CMD ["python3"]

If you continue in Step 4 there is a permission error because gsc-build needs root permissions.

 ---> Running in fd9c629d833a
 ---> 3d25746cc630
Step 8/28 : FROM postgres-graphene

 ---> c5f60706ecf3
Step 9/28 : RUN apt-get update     && env DEBIAN_FRONTEND=noninteractive apt-get install -y         binutils         libprotobuf-c-dev         locales         locales-all         openssl         python3         python3-pip         python3-protobuf     && python3 -B -m pip install protobuf jinja2 toml>=0.10

 ---> Running in 147832412b6a
Reading package lists...

E: Could not open lock file /var/lib/apt/lists/lock - open (13: Permission denied)
E: Unable to lock directory /var/lib/apt/lists/

Expected results

Graphene should use the root user to install dependencies.

Actual results

Graphene use the user given by the base image.

Is there any chance to use the USER keyword inside the base Dockerfile?

[dimakuv]

Good catch. Indeed, we just assumed the root user in GSC Dockerfiles.

@vahldiek Do you know of a quick fix for this?

[vahldiek]

I believe the easiest, since sudo is not always installed in docker images (and certainly not in ubuntu:18.04), would be to remove the USER keyword from the docker file and instead pass it as a runtime argument to docker run --user myuser.

Alternatively, one could generate the GSC image without the USER keyword and afterwards from the GSC image create another image that has the USER keyword. The dockerfile would look something like this:

FROM gsc-myimage

USER example

But I have no idea for a generic solution that doesn't involve root, since we need root privileges to install new packages. We could also build in a command into GSC which adds a particular user after all of GSC is done. But this would require an extra parameter either in the configuration or runtime argument to gsc build.

[tomolenet]

Thanks für your reply but I think there is one problem with these solutions. The entrypoint scripts need root permissions too. Or am I wrong?

https://github.com/oscarlab/graphene/blob/ce7cb4720007a8652c9408dfd19f98d50cc9c2bd/Tools/gsc/templates/apploader.template#L1-L13

[mkow]

It shouldn't, but maybe some permissions on the FS are wrong and that's why it fails? Overall running Graphene shouldn't require root, but on some distros it may require being in specific groups to get access to the SGX devices (/dev/sgx/*).

[tomolenet]

user@user-OptiPlex-3070:~/Developments/graphene/Tools/gsc$ docker run --device=/dev/sgx_enclave -v /var/run/aesmd/aesm.socket:/var/run/aesmd/aesm.socket gsc-postgres-graphene -c "whoami"
+ '[' -z '' ']'
+ GSC_PAL=Linux-SGX
+ /graphene/python/graphene-sgx-get-token -output /entrypoint.token -sig /entrypoint.sig
Attributes:
    mr_enclave:  e917708cdf2a5375ffa0fbd1c32d68727099ad1628375e92488b5ff49873dc41
    mr_signer:   f7eda00a2be415de0f32e77ac28121e7d20c9f2a979a689d0fc9403b46ed2ea9
    isv_prod_id: 0
    isv_svn:     0
    attr.flags:  0600000000000000
    attr.xfrm:   1f00000000000000
    misc_select: 00000000
    misc_mask:   00000000
    modulus:     7523c0d9dd361760a44614c88e3cce95...
    exponent:    3
    signature:   377fb62638719a3fdd8719a874f23d29...
    date:        2021-07-11
+ /graphene/Runtime/pal-Linux-SGX /graphene/Runtime/libpal-Linux-SGX.so init /entrypoint -c whoami
error: Using insecure argv source. Graphene will continue application execution, but this configuration must not be used in production!
root
user@user-OptiPlex-3070:~/Developments/graphene/Tools/gsc$ docker run --user=postgres --device=/dev/sgx_enclave -v /var/run/aesmd/aesm.socket:/var/run/aesmd/aesm.socket gsc-postgres-graphene -c "whoami"
+ '[' -z '' ']'
+ GSC_PAL=Linux-SGX
+ /graphene/python/graphene-sgx-get-token -output /entrypoint.token -sig /entrypoint.sig
usage: graphene-sgx-get-token [-h] --sig SIGNATURE [--output OUTPUT]
graphene-sgx-get-token: error: argument --output/-output: can't open '/entrypoint.token': [Errno 13] Permission denied: '/entrypoint.token'

This is what I did. But there are no permissions on /entrypoint.token.

[vahldiek]

The issue is that user IDs inside docker don't necessarily match the once found outside. The best discussion of this I could find is documented here: https://blog.gougousis.net/file-permissions-the-painful-side-of-docker/

Basically, when creating a new user ID inside Docker, make sure that it matches the user ID outside, otherwise file permission won't work. The same holds true for group memberships. So please make sure whatever user/group is allowed to access files and SGX devices matches what is found inside of Docker.

[tomolenet]

Thanks for your reply. That is true. But I do not mount the entrypoint.token or entrypoint.sig at any point in Docker. These files should be generated by /graphene/python/graphene-sgx-get-token. Maybe the custom user has no permissions to write at /?