13. December 2022

[mkow]

Agenda

(please write your proposed agenda items in comments under this discussion)

[monavij]

Linux capabilities - There was a request to see if Gramine can support Linux capabilities set of system calls capget()/capset()`.

[boryspoplawski]

Gramine has no notion of capabilities, so this makes little sense. All we could do would be to lie and provide some dummy values.

[monavij]

Maybe. And make these set of system calls as untrusted. In this case workload is relying on kernel to make sure it restricts access to kernel.

[boryspoplawski]

I don't understand your comment. What has host kernel to do with it?

[monavij]

Ok. You were proposing a dummy value return. I was thinking passthrough to kernel and that is why the host kernel comment. Let's discuss next week.

[monavij]

Discuss security model of fork in Gramine - In gramine when we fork, both processes are in same Gramine trust domain. So while the two run in isolated address space and are isolated by kernel. They inherit all the parent state including the gramine state and trust each other. So we may have weaker security isolation between parent and child.

[boryspoplawski]

FWIW: Linux does not isolate child process from parent, unless privileges were gained (e.g. setuid binary). Often all processes running by the same user are in the same "domain".

[boryspoplawski]

Also there are cases like inheriting open file descriptors, which essentially require all of the processes to be in the same security domain in Gramine (e.g. encrypted files, which need encryption key).

[monavij]

Sure. That is fine. But then Liunx allows you to release capabilities.
Also how about fork and exec use case? Especially we have several examples where a parent process is the workload receiver and then forks a child process and execs the new binary. We should be able to create that child process in a separate security domain from parent.

[boryspoplawski]

But then Liunx allows you to release capabilities.

Not sure what you mean and why is this related

Also how about fork and exec use case?

File descriptors are preserved across both (bar O_CLOEXEC).

We should be able to create that child process in a separate security domain from parent.

Should we?

Especially we have several examples where a parent process is the workload receiver and then forks a child process and execs the new binary.

I feel like we discussed this already. Anyway, you can always have the receiver completely in untrusted part, have the workload encrypted and only attest the decryptor (since you want separate security domains, decryptors cannot share the priv key, so they may very well be spawned by untrusted part).

[monavij]

Yes we have discussed this already, but I can see certain use cases where this may be needed. Let's discuss next week in our meeting and see if we need to do something different.

[ying2liu]

Some topics for enclave-cc project:

1. Add the missing system calls: Add new system calls to gramine #1058
2. Implement remote attestation software stacks for enclave-cc next year?
3. Avoid local attestation for unix domain socket in fork child/parent case.

[mkow]

Meeting notes

• Linux capabilities:
  • @monavij wants to passthrough capabilities-related syscalls to the host.
    • @mkow: This won't work on non-Linux hosts.
    • @mkow: It doesn't really restrict capabilities, because Gramine design assumes that all the processes are on the same privilege level and Gramine doesn't implement Linux permission model (users, namespaces, capabilities, etc.). It's hard/impossible to add, because in SGX we don't have hardware memory separation inside the enclave, so the process can read and manipulate Gramine state. We'd need to distrust other Gramine processes in IPC, which is super hard and maybe even impossible.
  • @monavij: What if we start all in-Gramine forked processes from a clean state, instead of inheriting it from the parent?
    • @mkow / @woju: This will break most of Linux apps - see e.g. inherited descriptors.
  • @mkow / @woju: We won't break the whole Gramine design for a use-case which someone doesn't even want to explain in detail to us.
  • @monavij: This is a generic feature which is limiting Gramine.
  • @mkow: Yes, but it's still not feasible to implement and goes against the core design of Gramine.
  • @monavij still believes that it's possible to implement, she'll think and propose some design.
  • // @mkow: That was an hour-long discussion, I tried to summarize only the most important points.