4 ms·

> Having people compile code to WASM to execute it in a sandbox is becoming quite widespread. Shopify is not the first company to do that. Whether or not a tec

> Having people compile code to WASM to execute it in a sandbox is becoming quite widespread. Shopify is not the first company to do that. Whether or not a technical solution is good is not dependent on it being employed by other companies. Using seccomp to run untrusted code is a better solution than wasm because it’s less code and more efficient.

the_mitsuhiko 6y ago
> Whether or not a technical solution is good is not dependent on it being employed by other companies You said it's state of the art and simpler as WASM. I'm not actually aware of a single company using seccomp for what Shopify is doing (letting people upload custom code) so I would be quite curious to hear who does.
- CyberRabbi 6y ago
  I never said anything was “state of the art” or made any claim that any company is using seccomp to accomplish what Shopify is doing. I said that companies typically run third party native code, e.g. imagemagick, in seccomp to process untrusted data, e.g. user-uploaded image files. If I were tasked with doing what Shopify is doing with wasm here, I would employ the seccomp-based solution since it’s equally applicable, it requires less code, and it’s more efficient. Whether or not other companies use a seccomp solution for this particular use case has no technical basis in determining its applicability for this use case. Seccomp was specifically designed for running untrusted code on your infrastructure, this exact use case.
  - tpetry 6y ago
    And i would run wasm with a seccomp profile: You have the benefit of language designed which is hard to not do anything malicious (i guess theres still some possibility) and harden the execution environment (wasm runner) within a rootless pofman/docker container with a seccomp profile and restrictive selinux labels. The world is not black and white, you can mix multiple solutions for more security. For what shopify is doing you need the most security you can get. Your example running a trusted application (imagemagick) with untrusted input is a lot easier to make secure than running untrusted binaries.
    - CyberRabbi 6y ago
      Using wasm in addition to seccomp-bpf (what you’re calling seccomp) strictly increases your attack surface. If you want to maximize security you would only use seccomp. Imagemagick is not trusted to process arbitrary data, otherwise there would be no need to use seccomp. Seccomp was specifically designed for running untrusted binaries. Check references if you do not believe me: https://en.wikipedia.org/wiki/Seccomp#History https://en.wikipedia.org/wiki/Seccomp#History
      - feanaro 6y ago
        > Using wasm in addition to seccomp strictly increases your attack surface. If you want to maximize security you would only use seccomp. Huh? How so?
        CyberRabbi 6y ago
        The wasm vm has to parse, validate, and compile untrusted input. It also exposes host calls. Those are all potential attack vectors. That’s at least roughly 50K LOC.
        imtringued 6y ago
        >It also exposes host calls. Only if you grant explicit access to them. What usually happens is that there is a vendor provided API that only gives you access to exactly what you need which is significantly less powerful than a complete linux process that can write to files, spawn background threads, etc all by default. Yes you can block access to these things but you're going to miss something at some point.
        CyberRabbi 6y ago
        In seccomp the only syscalls available are read, write, exit, and sigreturn. There is nothing to miss
      - alquemist 6y ago
devwastaken 6y ago
That's a pretty bold statement. I'd like to see an in depth analysis between the two before supporting that.
- CyberRabbi 6y ago
  It’s readily apparent: More efficient: using wasm has a necessary compilation or interpretation overheard. Seccomp doesn’t. Simpler: wasm requires deploying running an entire wasm runtime, likely >= 50K LOC in additional complexity and attack surface. Seccomp uses a small 100 line shim.
  - imtringued 6y ago
    You can run WASM to grant fine grained access to certain APIs. You might be able to do this with a sidecar that provides the API over HTTP and then let the untrusted process only access the side car but why do this when you can just grant API access to a WASM module? From the perspective of the third party user the API can be called directly via a function instead of doing a HTTP request.
  - devwastaken 6y ago
    "readily apparent" is not good evidence. Security isn't as simple as number of lines of code. You need actual in depth analysis to even know the attack surface. The reason why people view wasm as more secure is the runtimes used for it are VM's that control execution at an instruction level along with the wasm instruction set being far simpler than x86. Not saying wasm is magically secure because of this, there's not much actual security analysis of existing runtimes - but there are good reasons for why it can be viewed as more secure.
    - CyberRabbi 6y ago
      Wasm execution doesn’t exist in the abstract. Lucet, the vm in question, does no theoretical instruction-level mitigations of which you speak. It does, however, expose a larger attack surface than simply using seccomp (not seccomp-bpf).

the_mitsuhiko 6y ago

> Whether or not a technical solution is good is not dependent on it being employed by other companies You said it's state of the art and simpler as WASM. I'm not actually aware of a single company using seccomp for what Shopify is doing (letting people upload custom code) so I would be quite curious to hear who does.

CyberRabbi 6y ago
I never said anything was “state of the art” or made any claim that any company is using seccomp to accomplish what Shopify is doing. I said that companies typically run third party native code, e.g. imagemagick, in seccomp to process untrusted data, e.g. user-uploaded image files. If I were tasked with doing what Shopify is doing with wasm here, I would employ the seccomp-based solution since it’s equally applicable, it requires less code, and it’s more efficient. Whether or not other companies use a seccomp solution for this particular use case has no technical basis in determining its applicability for this use case. Seccomp was specifically designed for running untrusted code on your infrastructure, this exact use case.
- tpetry 6y ago
  And i would run wasm with a seccomp profile: You have the benefit of language designed which is hard to not do anything malicious (i guess theres still some possibility) and harden the execution environment (wasm runner) within a rootless pofman/docker container with a seccomp profile and restrictive selinux labels. The world is not black and white, you can mix multiple solutions for more security. For what shopify is doing you need the most security you can get. Your example running a trusted application (imagemagick) with untrusted input is a lot easier to make secure than running untrusted binaries.
  - CyberRabbi 6y ago
    Using wasm in addition to seccomp-bpf (what you’re calling seccomp) strictly increases your attack surface. If you want to maximize security you would only use seccomp. Imagemagick is not trusted to process arbitrary data, otherwise there would be no need to use seccomp. Seccomp was specifically designed for running untrusted binaries. Check references if you do not believe me: https://en.wikipedia.org/wiki/Seccomp#History https://en.wikipedia.org/wiki/Seccomp#History
    - feanaro 6y ago
      > Using wasm in addition to seccomp strictly increases your attack surface. If you want to maximize security you would only use seccomp. Huh? How so?
      - CyberRabbi 6y ago
        The wasm vm has to parse, validate, and compile untrusted input. It also exposes host calls. Those are all potential attack vectors. That’s at least roughly 50K LOC.
        imtringued 6y ago
        >It also exposes host calls. Only if you grant explicit access to them. What usually happens is that there is a vendor provided API that only gives you access to exactly what you need which is significantly less powerful than a complete linux process that can write to files, spawn background threads, etc all by default. Yes you can block access to these things but you're going to miss something at some point.
        CyberRabbi 6y ago
        In seccomp the only syscalls available are read, write, exit, and sigreturn. There is nothing to miss
    - alquemist 6y ago

devwastaken 6y ago

That's a pretty bold statement. I'd like to see an in depth analysis between the two before supporting that.

CyberRabbi 6y ago
It’s readily apparent: More efficient: using wasm has a necessary compilation or interpretation overheard. Seccomp doesn’t. Simpler: wasm requires deploying running an entire wasm runtime, likely >= 50K LOC in additional complexity and attack surface. Seccomp uses a small 100 line shim.
- imtringued 6y ago
  You can run WASM to grant fine grained access to certain APIs. You might be able to do this with a sidecar that provides the API over HTTP and then let the untrusted process only access the side car but why do this when you can just grant API access to a WASM module? From the perspective of the third party user the API can be called directly via a function instead of doing a HTTP request.
- devwastaken 6y ago
  "readily apparent" is not good evidence. Security isn't as simple as number of lines of code. You need actual in depth analysis to even know the attack surface. The reason why people view wasm as more secure is the runtimes used for it are VM's that control execution at an instruction level along with the wasm instruction set being far simpler than x86. Not saying wasm is magically secure because of this, there's not much actual security analysis of existing runtimes - but there are good reasons for why it can be viewed as more secure.
  - CyberRabbi 6y ago
    Wasm execution doesn’t exist in the abstract. Lucet, the vm in question, does no theoretical instruction-level mitigations of which you speak. It does, however, expose a larger attack surface than simply using seccomp (not seccomp-bpf).