Wasmtime GitHub notifications bot (Apr 05 2025 at 10:52): Wasmtime GitHub notifications bot (Apr 05 2025 at 10:52):rikhuijzer opened issue #10527:
Feature
As a feature request, I was thinking that it might be useful for Wasmtime to support an allowlist for domains that the wasm may connect to. This would be similar to the
Content-Security-Policyin browsers.cargo component sometool --allow-domains="wasmtime.dev,webassembly.org"Benefit
The benefit would be additional security. As recently was shown again with the attack on the tj-actions/changed-files, attackers can use supply chain attacks to obtain secrets. In this particular attack they used the GitHub Actions logs, but sending them to their own servers has happened before as well.
Alternatives
Alternatively, this could be ensured during compile time? I haven't seen a tool for it yet but I can imagine it's would be possible.
If this feature request is not considered a good feature then please feel free to close this issue.
Wasmtime GitHub notifications bot (Apr 09 2025 at 09:01):rajatjindal commented on issue #10527:
I had similar thoughts and had started work on https://github.com/rajatjindal/spin-trigger-ghaction but didn't finish it yet.
Wasmtime GitHub notifications bot (Apr 09 2025 at 09:14):rikhuijzer commented on issue #10527:
I had similar thoughts and had started work on https://github.com/rajatjindal/spin-trigger-ghaction but didn't finish it yet.
Very nice. I’m very supportive of any attempt at improving GitHub Actions security.
For clarification though, my feature request here is not necessarily about GitHub Actions. The aim is to restrict wasm executables privileges. Currently, http can either be allowed or disallowed, but I can imagine that more fine-grained settings could be useful to avoid a random dependency sending data to some malicious server.
Wasmtime GitHub notifications bot (Apr 10 2025 at 20:29):pchickey closed issue #10527:
Feature
As a feature request, I was thinking that it might be useful for Wasmtime to support an allowlist for domains that the wasm may connect to. This would be similar to the
Content-Security-Policyin browsers.cargo component sometool --allow-domains="wasmtime.dev,webassembly.org"Benefit
The benefit would be additional security. As recently was shown again with the attack on the tj-actions/changed-files, attackers can use supply chain attacks to obtain secrets. In this particular attack they used the GitHub Actions logs, but sending them to their own servers has happened before as well.
Alternatives
Alternatively, this could be ensured during compile time? I haven't seen a tool for it yet but I can imagine it's would be possible.
If this feature request is not considered a good feature then please feel free to close this issue.
Wasmtime GitHub notifications bot (Apr 10 2025 at 20:29):pchickey commented on issue #10527:
I'm pretty sure the HTTP allowlist issue has been discussed before, but I can't find it in our issue tracker.
In short: right now you can't enforce an http domain allowlist with the wasmtime-cli, and I don't think we are going to add support for it in the near future.
If you want to solve this problem with wasmtime today, you will need to make your own wasmtime embedding, and customize your implementation of https://docs.rs/wasmtime-wasi-http/31.0.0/wasmtime_wasi_http/trait.WasiHttpView.html#method.send_request to first check that the authority matches some allowlist stored in your context, and if accepted pass the request to https://docs.rs/wasmtime-wasi-http/31.0.0/wasmtime_wasi_http/types/fn.default_send_request.html which provides the default implementation of that method.
In general we want wasmtime-cli to provide a useful way to run components, but it isn't intended to be configured to handle "policies" such as network allow lists or deny lists. For now, if you want to add access control policies, you need to do so in the host by using the wasmtime, wasmtime-wasi, and wasmtime-wasi-http crates directly. Those crates have Rust APIs are much richer than we can expose through the cli, and the overwhelming share of production uses of wasmtime are by way of custom embeddings of those crates, rather than through the cli tool.
Specifically to the case of access control policies, the Bytecode Alliance vision is that this problem will be solvable with component model virtualization, where you can take a component that imports
wasi:http/outgoing-handlerand compose it with a component that both exports and imports that same interface, applying the policy and proxying the rest to the imported interface. (There is an early attempt at this at https://github.com/bytecodealliance/WASI-Virt but its not production ready.) The big roadblock is that in WASI 0.2, component composition doesn't work out very well in practice, because readiness, streams and futures are taken care of through resources, which ends up making composition quite inefficient unwieldy. We are resolving the design problems that make this difficult in the Component Model and WASI 0.3 by providing first-class support for async in the Component Model. This work is still under development and is expected to ship in the next few months. Once the standard and its host implementations ship, then folks will have time to revisit the WASI-Virt project and/or build other ways to add policies to components, and you'll be able to apply an ACL to a component before running it in wasmtime-cli, or in any other wasi host implementation.I'm going to close this issue because this answer describes both a workaround and the way a better answer will be available in the future, but I'm happy to continue discussion here and help you understand this issue more.
Wasmtime GitHub notifications bot (Apr 10 2025 at 20:51):rikhuijzer commented on issue #10527:
@pchickey Thank you for the in-depth clarification. Very useful. I also like it that you closed it. Clear communication. I appreciate that. :+1:
Last updated: Dec 06 2025 at 07:03 UTC