Request for classic confinement & aliases: ego-dev

Hey :wave:

we’d like to request classic confinement and default aliases for our snap ego-dev.

EGo is a framework for building confidential apps in Go, which can be run in always-encrypted and verifiable enclaves on Intel SGX-enabled hardware.

This is our website and our GitHub project page: Website: https://www.ego.dev/ GitHub: https://github.com/edgelesssys/ego

Classic confinement: Given that we ship a slightly modified Go compiler and that access to the Intel SGX block devices is required, which is exposed by either Linux 5.11+ or on previous versions by an already-installed Intel SGX kernel module, we would like to access the --classic confinement.

If you think there is a clever way to avoid requesting --classic by default and rather run in strict mode without too many hurdles, let us know, we would definitely prefer it!

Default aliases We were told that uploading our snap under ego itself was not generally permitted due to the short name. Under this circumstance, and considering that our tools use ego as a prefix anyway, we would like to request the following aliases, which follow the convention we currently use on our .DEB releases:

snap alias ego-dev.ego ego
snap alias ego.dev.ego-go ego-go
snap alias ego-dev.ego-gdb ego-gdb

@edgelesssys:

If you are shipping a Go compiler, it’s my understanding that you will be able to remain under strict confinement if you plug some interfaces that could allow ego to access what it needs (perhaps block-devices and kernel-module-observe? ).

A handy tool to understand which interfaces you could plug while keeping under strict confinement is snappy-debug. You can locally run snappy-debug in one terminal and ego in another one and watch the output of snappy-debug. It usually makes useful suggestions about which interfaces you need based on the behavior it observes in your snap. Can you please try and let us know? Feel free to paste here the denials you see and we will be happy to assist.

@emitorino:

After thinking for a moment about our use case here, I am not sure if it actually makes sense to run under strict confinement.

While we might be able to use the Go compiler under strict confinement (though it could get awkward to use, as we would need to ship or access other tools such as git, gcc and co.), I think aiming for strict confinement will fail at the point where a user would use our tool to run a program.

Technically, interfaces such as block-devices and kernel-module-observe should make it possible to execute applications running under Intel SGX (same way as it works in Docker). At least in SGX-simulation mode (a mode for running and testing applications on non-SGX systems), applications do run successfully this way.

Yet, EGo still is a generic runtime to run Go applications. We do not know what kind of program the user is going to run and which resources it wants to access. Running under strict confinement will limit the features to the interfaces EGo was granted, and it is hard to specify the interfaces we want to use. It could be possibly almost anything a Go program could request.

In addition, access to local files would also be great, depending on what kind of application is running and which files it might access from a host. Right now, EGo works mostly transparent (gives full access to the host file system), but in an upcoming release, we provide the user the possibility to mount specific paths from the host system inside the enclave, thus technically we are implementing another layer of sandbox here under the assumption of having (mostly) full host access.

Under these circumstances, I am not sure if it makes sense to aim for strict confinement after all. Or do you have a suitable suggestion here on how we could handle this in a convenient way?

@edgelesssys,

Can you please confirm if ego-dev needs access to files from the host for the purposes of compilation? i.e.: host’s installed header files (e.g.: in /usr/include); .so files (e.g.: in /lib and /usr/lib); /usr/local/src, etc. The snap’s runtime environment won’t contain these files so if that’s the case we can consider ego-dev follows under the supported compilers category and thus the requirements for classic confinement are understood.

@emitorino

With cgo enabled, that should be the case, yes.

The requirements for classic are understood. @advocacy, can you please perform the vetting?

@advocacy ping, could you please perform publisher vetting?

+1 from me, I verified the publisher.

Granting use of classic. This is now live.

Great to see, thank you for the review!

Any chances we could also request the aliases mentioned in the opening post? As far as we know, there should not be other common tools having “ego” as command name.

Otherwise we would need to get a little creative here to accumulate it. Not impossible, but having default aliases definitely seem like the more user friendly option for us here.

@edgelesssys apologize, the alias request was missed. +1 from me to grant the requested aliases:

Can other @reviewers please vote?

+1 from me. I am not aware of any other applications using this namespace. Just to be on the safe side, @emitorino @edgelesssys can you quickly check/confirm that there are no other (existing) applications that could potentially use these?

None that we are aware of, also no matches in the suggested packages when typing in “ego” on a clean Ubuntu system.

1 Like

+2 votes for, 0 votes against, Granting the requested auto-aliases: