SIP for dependency isolation

[itowlson]

Technology POC with terrible names, poor formatting, and questionable consistency at https://github.com/itowlson/spin/tree/dep-isolation with a partial test case at https://github.com/itowlson/spin-dep-isolation-test.

(The POC doesn't yet have KV because Wasmtime 47 had a bug with named-importing interfaces with hyphens in them: Wasmtime 48 fixed that and I'll get the POC KVed up shortly.)

[dicej]

Thanks for writing this up!

[dicej]

I'm not sure I understand the value the GUIDs would add here. If we were to deny-adapt dependency imports by default (regardless of whether they're named imports or not) and require that the app developer specify explicitly which imports they want to make available to the dependency in a restricted or unrestricted form, there would be no way for the dependency to forge anything.

In your example, a dependency that named-imports super-secret-db-password would have that import denied by default, and the app developer would have to explicitly indicate if they wanted it hooked up to anything.

I guess I don't understand what the "and persuades me to use it in a composition" scenario looks like and how GUIDs would help avoid it.

[itowlson]

Hmm, maybe you're right. I am not sure how the deny adapter would apply itself to named imports. But I worry there is still a case where a dependency has a legitimate import (dependency imports SQLite and this is known and allowed), which will be mapped to a named import, but the dependency also forges a pre-named import of the same interface. In the prototype, I link all the dep's named imports. But this could be somewhat mitigated by passing the list of "names we made up" and only linking those. But I still worry that there is a more-complicated-still scenario where Evil Dep forges a name that it guesses will be used by Good Dep and we can't tell them apart. Maybe we can do additional decoration to avoid this.

But basically my worry is kind of if we trust names as indicators of permissions, we are trusting something potentially controlled by an attacker. Perhaps I am seeing phantoms!

[dicej]

To me, the key is that we would deny-adapt all dependency imports by default, regardless of whether they are named or not, and require the app manifest to specify explicitly which imports they want to connect to the host, if any. A dep that named-imports super-secret-db-password would only get access to a host resource of the same name if the app explicitly says it should by saying (in TOML-ese) "connect dep $x's super-secret-db-password to the host's super-secret-db-password". Alternatively, the app manifest could say "connect dep $x's super-secret-db-password to the host's fake-db-password-ha-ha". But unless the app manifest explicitly says what to connect that import to, it just gets denied.

The metaphor I'm thinking of is mobile (e.g. Android) app permissions. An app can say "I need access to your camera to do my job, may I?", but you as the user get to decide (and are indeed required to decide) what the answer is. Similarly, a dep component can say "I need access to such-and-such resource to do my job, may I?", and the app author can say "yes", "no" (the default), or "here's something else with the right shape (but maybe fake), make do". Indeed some aftermarket mobile OSes let you do the equivalent of the last option by giving an app access to fake location data when it asks for your location.

[itowlson]

Okay, I see where you're coming from. We proactively deny all named imports on each dep, and then plug unnamed imports to named imports. This will work today: I guess in the future Till envisages and Lann notes, we will want/need to rethink all this stuff anyway.

So this allows us to trust names, as any attacker controlled names will be squished (even in precomposition scenarios), and we can ditch the GUIDs in favour of predictable (or even reversible) names.

[alexcrichton]

Agreed with all the conclusions here and it all seems pretty reasonable to me 👍

[lann]

This looks viable for the current Spin interfaces, but since @tschneidereit isn't here to do it I'll point out that in the long run it would be great to use named imports for this directly, replacing the pattern of open("my-store") with an import named my-store.

In theory we could even make this additive with existing interfaces, e.g.

package spin:key-value@3.1.0;

interface opener {
  open: async func() -> result<store, error>;
}

interface key-value {
  resource store {
    // This stays, but can't be isolated!
    open: static async func(label: string) -> result<store, error>;

Dependency isolation would then be pushed back to composition time rather than run time.

[fibonacci1729]

IIUC random GUIDs will make composition non-deterministic. This means the composed Wasm differs on every spin build. Given that, I'd suggest a deterministic structured key derived from (component id, dependency name, capability, interface) -- e.g. spin-cap:<component>/<dep>/<capabilitiy>/<interface>.

[itowlson]

If we're confident that the forgery concern is a non-issue then I'm happy to go back to this (this was what the prototype did until I got in a funk over predictable names).

[itowlson]

@lann Yes, I thought about that, but that involves more rework of the SDKs than I suspect we want to take on as part of this.

The flow there is certainly simpler: we validate each dependency's set of named imports agains spin.toml, then compose naively. I think we still have considerations around name collisions, although I guess we have those in the current proposal too. If folks think this is the way to go then I can have a tinker.