11. April 2023

[dimakuv]

Agenda

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

• capset/capget discussion

Misc

Dmitrii: Why do we have two similar PRs from Fortanix, but done in very different ways/styles? Talking about

• Adding max_map_count support to /proc #1254
• [LibOS] Add support for two new pseudo files in /proc dir #1245

Unfortunately, Fortanix folks didn't show up to today's meeting, so we'll ask them next time.

Woju: we got the quote (GitHub Pages design) and we hope to get the budget for the website from CCC.

Mona: Gramine should graduate from a "sandbox" to "incubator", we already satisfy their requirements (most importantly, production usages).

capget/capset

Fortanix folks didn't investigate the application, they looked at the strace, saw that capget/capset returns ENOSYS and that's how the application fails, so they added a passthrough implementation.

Mona: our guidance for such cases should be: understand what the application in question wants and try to implement the required functionality in a dummy (completely inside the SGX enclave) way.

• Woju: Linux capabilities are used to make apps more secure (by revoking unneeded capabilities). This "improving security" characteristic is lost in the SGX threat model. Then it becomes a mismatch of threat models (what the application thinks about its own "semi-sandbox" environment it "created" by calling capset and what Gramine-SGX actually performed -- which is nothing if we use "dummy" implementations).
• Michal: Woju's comment mixes two separate security domains. This should be solved at the level of a separate sandbox that the host generates for the Gramine-SGX app. Then you would have a two-way sandbox, which should be the proper deployment of Gramine. In this deployment, changing capabilities becomes a no-op, and thus could be simulated as no-ops in Gramine.
• Michal: even if we would implement passthrough (and solve associated security issues), then it would tie us to the Linux host. How could we do it on e.g. a Windows host?
• Michal/Woju: this should be enabled by a separate manifest option. And we need to document it and also put log_warning() messages to explain that applications running inside Gramine-SGX will not benefit from capabilities (because they are dummy).
• Mona: we should collect more info on how applications (that people may want to put into Gramine) use Linux capabilities. Based on the usages, we can decide in the future whether to have (a) complete no-op, (b) complete passthrough, (c) passthrough in set direction, no-op in get direction, (d) something in between.
• Dmitrii: I second Michal's proposal. Well, we could go through different capabilities and have per-capability decisions (e.g., CAP_SYS_NICE seems to be security-irrelevant and can always be implemented as a no-op).