Stream: wasmtime

Topic: Runtime sandbox changes


view this post on Zulip Joe Sylve (Aug 26 2024 at 18:31):

If I wish to change a component's access at runtime, is it okay to switch out it's WasiCtx after the instance is created?

view this post on Zulip Joe Sylve (Aug 26 2024 at 18:31):

For example, if I want to give it access to another folder on the host.

view this post on Zulip Alex Crichton (Aug 26 2024 at 18:34):

That should be fine yeah, and while the methods don't currently exist I think it would make sense to additionally add methods to WasiCtx to do this on-the-fly so you don't have to create a whole new context

view this post on Zulip Joe Sylve (Aug 26 2024 at 18:34):

Or at least make WasiCtx cloneable

view this post on Zulip Joe Sylve (Aug 26 2024 at 18:35):

although I guess that doesn't matter is you can't change the state without the builder.

view this post on Zulip Alex Crichton (Aug 26 2024 at 18:35):

Cloning might be a bit tougher since it can contain things like closures, but yeah mutation should be relatively easy to add

view this post on Zulip Dave Bakker (badeend) (Aug 26 2024 at 19:00):

Depends on what you mean by "change" access. Mutating the WasiCtx (or swapping it out entirely) might work for new resources, but it won't automatically revoke access to already-opened resources.

view this post on Zulip Joe Sylve (Aug 26 2024 at 19:01):

That was the idea.

view this post on Zulip Dave Bakker (badeend) (Aug 26 2024 at 19:03):

Also, multiple properties are expected to never change during the lifetime of a component instance. Such as: filesystem preopens, insecure-seed

view this post on Zulip Joe Sylve (Aug 26 2024 at 19:05):

Can you point me to a reference please?

view this post on Zulip Dave Bakker (badeend) (Aug 26 2024 at 19:07):

Sorry, I updated my previous answer at the same time as your question. See previous comment

view this post on Zulip Dave Bakker (badeend) (Aug 26 2024 at 19:07):

Some mor eexamples: wasi-cli -> get-environment, get-arguments, initial-cwd

view this post on Zulip Dave Bakker (badeend) (Aug 26 2024 at 19:24):

Mutating the WasiCtx might work for new resources, but it won't automatically revoke access to already-opened resources.

And at the same time, updating socket_addr_check & allowed_network_uses would immediately apply to both the old _and_ new sockets.

So thinking about it more, I would be very careful about mutating any property on an WasiCtx that is already in use. I see issues ranging from "subtly wrong" to straight up TOCTOU security vulnerabilities.

view this post on Zulip Joe Sylve (Aug 26 2024 at 19:26):

Is there a current best practice for managing guest permissions at runtime then or would this currently require unloading and reloading the component?

view this post on Zulip Dave Bakker (badeend) (Aug 26 2024 at 19:31):

Do you have any specific permissions in mind?

view this post on Zulip Joe Sylve (Aug 26 2024 at 19:34):

Dynamically granting component extensions access to file's on the host is the current use case I'm considering.

view this post on Zulip Dave Bakker (badeend) (Aug 26 2024 at 19:45):

Do you have a custom contract between your host application and the extensions? Because, while the WASI preopens should remain static, you may be able to expose your own method that opens files dynamically

view this post on Zulip Joe Sylve (Aug 26 2024 at 19:46):

Yes, I'm working on a plugin system, so I"m in control of the API


Last updated: Nov 22 2024 at 16:03 UTC