Show HN: Sandboxing untrusted code using WebAssembly(github.com)
76 pointsby mavdol044 days ago9 comments
  • csense3 days ago
    I had to do some research to figure out what this is actually doing. When you try to pass e.g. strings through WASM functions you end up writing the data to memory and passing offset / length, which is obviously inconvenient and potentially has security implications. WASM components [1] is a spec that tries to improve on this with an IDL called WIT that lets you define functions that pass complex types with a proper ABI.

    This all seems sensible for languages like C or Zig that neatly cross compile to WASM. But I was very confused how this could ever work with a duck-typed interpreted language like Python, so I did some digging.

    Apparently "run your Python as WASM" part is implemented by componentize-py which cross compiles CPython to WASM as libpython3.14.so [2].

    I'm not sure whether I should be impressed or horrified...

    [1] https://component-model.bytecodealliance.org/

    [2] https://github.com/bytecodealliance/componentize-py/blob/79e...

    • txdv3 days ago
      js string builtin in wasm is a thing now, might be sharable across runtimes with special compile flags
      • davexunit2 days ago
        The annoying thing about that proposal is having to use 16 but code units instead of 8 bit. I hope the stringref proposal can get beyond phase 1 because that does strings right imo.
  • yohguy4 days ago
    It looks really promising but I would love more examples as to how to actually use this with AI agents. Reading the homepage it is not clear if we are meant to have the Agent spun up and act fully in the sandbox (something like the HTTP example) or do we take the result code message from an AI agent and then run it dynamically (with eval?).

    That being said this is useful even if it wasn't for the running AI agent code aspect, being able to limit ram and cpu usage and time outs makes it easier to run coding based games/applications safely (like battle snakes and Leetcode)

    • mavdol044 days ago
      Thanks! Got it, I will add more examples for that. Currently you can do both: run dynamically untrusted code with eval, or run fully encapsulated logic (like in the existing examples).

      I made a small example that might give you a better idea (it's not eval, but shows how to isolate a specific data processing task): https://github.com/mavdol/capsule/tree/main/examples/javascr...

      And yes, you are spot on regarding LeetCode platforms. The resource limits are also designed for that kind of usage.

      • zachrip4 days ago
        Would like to see the eval version - the dialogue version just seems like normal code with extra steps?
        • mavdol044 days ago
          yeah, the previous example was quite basic. I will write a complete example for that, but here is how you can run dynamic code:

             import { task } from "@capsule-run/sdk";

   export default task({
     name: "main",
     compute: "HIGH",
   }, async () => {
     const untrustedCode = "const x = 10; x * 2 + 5;";
     const result = eval(untrustedCode);
     return result;
   });
          Hope that helps!
          • zachrip2 days ago
            Is the code in the eval also turned into wasm first then? Does this work as a JIT for wasm?
            • mavdol04a day ago
              It actually works a bit differently. The eval is executed by the interpreter running inside the isolated wasm sandbox (StarlingMonkey). You can think of it as each sandbox having its own dedicated JavaScript engine.
      • fix4fun4 days ago
        yep, more examples with agents use will be helpful
  • Asmod4n4 days ago
    Mruby has something like that build in, you can create a VM which only has basic data types and control flow, no i/o, rng, time, meta programming or any host access possible simply because most functionality is only available as gems and they simply aren’t loaded. Everything you can do with it should be fully deterministic.
  • koolala4 days ago
    It seems import to highlight these more. Aren't all the limitations of using this based around their limitations?

    componentize-py – Python to WebAssembly Component compilation

    +

    jco – JavaScript toolchain for WebAssembly Components

    I'm curious how Wasi 0.3 cross language components will go for something like this.

    • avaer4 days ago
      I agree; this project looks impressive, but I'm guessing there are some rough edges in the transpilation "magic" that should be called out.

      That's the crux of how usable this is going to be for people's use cases, and it's better to document the limitations upfront.

    • mavdol044 days ago
      I recreated many Node.js built-ins so compatibility is actually quite extended.

      For Python, the main limitation is indeed C extensions. I'm looking for solutions. the move to WASI 0.3 will certainly help with that.

  • gregpr074 days ago
    Why go this route? Why Python is more powerful than JS is mostly because of third party plugins like pandas which are excplicitly not supported (C bindings, is this possible to fix?)...

    At that point it might be just easier to convince the model to write JS directly

    • simonw4 days ago
      You can run libraries like Pandas in WebAssembly in Pyodide - in fact Pandas works already. Here's a demo I built with it a while ago: https://tools.simonwillison.net/pyodide-bar-chart

      It's not too hard to compile a C extension for Python to a WebAssembly and bundle that in a .so file in a wheel. I did an experiment with that the other day: https://github.com/simonw/tiny-haversine?tab=readme-ov-file#...

      • mavdol044 days ago
        I would love for the component model tooling to reach that level of maturity.

        Since the runtime uses standard WASI and not Emscripten, we don't have that seamless dynamic linking yet. It will be interesting to see how the WASI path eventually converges with what Pyodide can do today regarding C-extensions.

    • mavdol044 days ago
      I understand your point. I added native Python support because C extensions will eventually become compatible. Also, we might see more libraries built with Rust extensions appearing, which will be much easier to port to Wasm.
  • bigblind4 days ago
    This looks very neat indeed! Are there any plans to adding network limits? Like, you might want to avoid an agent running code that just requests a resource in a loop, or downloads massive amounts of data.
    • mavdol044 days ago
      Thanks! Not yet, but that's a great idea. I could definitely add it to the roadmap.
  • skybrian3 days ago
    If it's a coding agent, it will need to be able to write scripts and run them. I haven't tried just-bash, but it seems interesting for comparison:

    https://github.com/vercel-labs/just-bash

  • simonw4 days ago
    The decorator syntax is neat but confusing to me - I would need to understand exactly what it's doing in order to trust it.

    I'd find this a lot easier to trust it if had the Python code that runs in WASM as an entirely separate Python file, then it would be very clear to me which bits of code run in WASM.

    • smithclay4 days ago
      Personally: love the decorator pattern after I got used to it :)

      Posted this yesterday as well, but seems like a really nice emerging pythonic way to call out to remote infrastructure (see: Modal[1]).

      [1]: https://modal.com/docs/examples/hackernews_alerts#defining-t...

    • mavdol044 days ago
      Thanks for the feedback! What do you think about running the separate file directly from the decorator?
      • simonw4 days ago
        I'd love that. I want to be able to look at the system and 100% understand which code is running directly and which code is running inside the sandbox.
  • asyncadventure4 days ago
    [dead]