6 ms·

Technically you can accomplish the same thing using seccomp, I.e. the way most services run third party native code to process untrusted data, e.g. imagemagick.

Technically you can accomplish the same thing using seccomp, I.e. the way most services run third party native code to process untrusted data, e.g. imagemagick. That’s what I would probably do since it’s more efficient and simpler. No need for a compilation step or an interpreter. No need to trust the (likely complex) webassembly runtime to be bug free. Edit: most responses are being made under the assumption that seccomp is the same as seccomp-bpf. The two are different and designed for different use cases. For example it is not possible to run a wasm JIT entirely under seccomp but is possible under seccomp-bpf. Seccomp was specifically designed for the use case described in this article by Shopify. You can read more about the differences here https://en.wikipedia.org/wiki/Seccomp https://en.wikipedia.org/wiki/Seccomp

xg15 6y ago
I think WASM has the added benefit of being platform-independent - which is generally a good thing but can even be a security feature: With native code, even if run without privileges, you need to expose a lot of details about your hardware that malicious users could use to find vulnerabilities. With WASM, the host can keep the actual hardware architecture and even the actual machine code that is generated a secret.
- CyberRabbi 6y ago
  Yeah but there’s a nearly 100% chance your server platform is x86 and in the case that it changes, it will be a gradual change in the long term. While it’s nice to have the platform independence, it has nearly zero practical utility here. If you’re making a security argument, using seccomp over a complex webassembly runtime reduces your attack surface.
- croes 6y ago
  Security by obscurity?
feanaro 6y ago
Shopify is already a known seccomp user (for running Ruby in the mruby VM), so I think there's no reason to assume the WebAssembly runtime is not in a seccomp jail too.
- CyberRabbi 6y ago
  That’s just redundant
  - garethrowlands 6y ago
    Redundancy is sometimes good. When it comes to containing exploits, surely it's better to be safe than sorry.
  - emteycz 6y ago
    Exactly, and there is probably a third redundancy too.
  - eloff 6y ago
    I don't think you get security. It's about threat mitigation. There is nothing secure, including seccomp jails. You want defence in depth - that is using multiple layers of defence to reduce the risk. You can never get it to 0, but if you combine two mechanisms that are each 99% effective, then your risk is now 0.01% instead of 1%. That's obviously an improvement. You don't run your database without a password (hopefully) just because its behind a firewall. You want to have the password as well in case an attacker finds a way around your firewall (compromises a system on the inside) or you misconfigure your firewall. Security in the physical world works the same way. You don't turn off the alarm and leave the bank doors open at the end of the day just because your vault is quite secure.
    - CyberRabbi 6y ago
      I don’t think you get the difference between seccomp and seccomp-bpf
      - eloff 6y ago
        You've been downvoted to oblivion. Don't you think that's a sign that maybe you're wrong?
        6y ago
the_mitsuhiko 6y ago
There is a big difference between running "third party native code" that you have some level of trust of (eg: image magick) vs having customers upload code to your infrastructure. In the latter case I'm not aware of a single service that uses seccomp to do this. The closest to a non WASM setup is either things like Firecracker or to enforce some sense of sandboxed language like JavaScript. Seccomp quite often plays a role in keeping those sandboxes safe, but it's generally not used to have people execute arbitrary binary blobs on SaaS. 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.
- CyberRabbi 6y ago
  > 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.
alquemist 6y ago
It's not an either/or. Most likely Shopify runs WASM inside an seccomp enclosure. Possibly inside a VM as well. Defense in depth.
- CyberRabbi 6y ago
  Running untrusted code in a wasm vm doesn’t add any extra defense over just using seccomp. It just adds unnecessary overhead and increases attack surface.
  - alquemist 6y ago
    Assuming that Intel / ARM microarch implementations are bug free, that is correct. In the real world there are no bug free implementations. Edit. This is the strategy Chrome sandboxing uses: a hardened runtime (JS/WASM) inside a seccomp enclosure. https://chromium.googlesource.com/chromiumos/docs/+/master/sandboxing.md https://chromium.googlesource.com/chromiumos/docs/+/master/s...
    - CyberRabbi 6y ago
      Running code in a wasm vm doesn’t magically prevent user code from exploiting uarch bugs. Lucet specifically does not mitigate spectre variant 2.
  - feanaro 6y ago
    seccomp escapes are a thing and if you're inside a restrictive environment such as WASM, it is harder to achieve it.
    - CyberRabbi 6y ago
      I think you’re referring to seccomp-bpf. seccomp has never been escaped and it is unlikely such a bug could happen due its simplicity. If you do not know the difference between seccomp and seccomp-bpf, please check references: https://en.wikipedia.org/wiki/Seccomp https://en.wikipedia.org/wiki/Seccomp

xg15 6y ago

I think WASM has the added benefit of being platform-independent - which is generally a good thing but can even be a security feature: With native code, even if run without privileges, you need to expose a lot of details about your hardware that malicious users could use to find vulnerabilities. With WASM, the host can keep the actual hardware architecture and even the actual machine code that is generated a secret.

CyberRabbi 6y ago
Yeah but there’s a nearly 100% chance your server platform is x86 and in the case that it changes, it will be a gradual change in the long term. While it’s nice to have the platform independence, it has nearly zero practical utility here. If you’re making a security argument, using seccomp over a complex webassembly runtime reduces your attack surface.
croes 6y ago
Security by obscurity?

feanaro 6y ago

Shopify is already a known seccomp user (for running Ruby in the mruby VM), so I think there's no reason to assume the WebAssembly runtime is not in a seccomp jail too.

CyberRabbi 6y ago
That’s just redundant
- garethrowlands 6y ago
  Redundancy is sometimes good. When it comes to containing exploits, surely it's better to be safe than sorry.
- emteycz 6y ago
  Exactly, and there is probably a third redundancy too.
- eloff 6y ago
  I don't think you get security. It's about threat mitigation. There is nothing secure, including seccomp jails. You want defence in depth - that is using multiple layers of defence to reduce the risk. You can never get it to 0, but if you combine two mechanisms that are each 99% effective, then your risk is now 0.01% instead of 1%. That's obviously an improvement. You don't run your database without a password (hopefully) just because its behind a firewall. You want to have the password as well in case an attacker finds a way around your firewall (compromises a system on the inside) or you misconfigure your firewall. Security in the physical world works the same way. You don't turn off the alarm and leave the bank doors open at the end of the day just because your vault is quite secure.
  - CyberRabbi 6y ago
    I don’t think you get the difference between seccomp and seccomp-bpf
    - eloff 6y ago
      You've been downvoted to oblivion. Don't you think that's a sign that maybe you're wrong?
      - 6y ago

the_mitsuhiko 6y ago

There is a big difference between running "third party native code" that you have some level of trust of (eg: image magick) vs having customers upload code to your infrastructure. In the latter case I'm not aware of a single service that uses seccomp to do this. The closest to a non WASM setup is either things like Firecracker or to enforce some sense of sandboxed language like JavaScript. Seccomp quite often plays a role in keeping those sandboxes safe, but it's generally not used to have people execute arbitrary binary blobs on SaaS. 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.

CyberRabbi 6y ago
> 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.

alquemist 6y ago

It's not an either/or. Most likely Shopify runs WASM inside an seccomp enclosure. Possibly inside a VM as well. Defense in depth.

CyberRabbi 6y ago
Running untrusted code in a wasm vm doesn’t add any extra defense over just using seccomp. It just adds unnecessary overhead and increases attack surface.
- alquemist 6y ago
  Assuming that Intel / ARM microarch implementations are bug free, that is correct. In the real world there are no bug free implementations. Edit. This is the strategy Chrome sandboxing uses: a hardened runtime (JS/WASM) inside a seccomp enclosure. https://chromium.googlesource.com/chromiumos/docs/+/master/sandboxing.md https://chromium.googlesource.com/chromiumos/docs/+/master/s...
  - CyberRabbi 6y ago
    Running code in a wasm vm doesn’t magically prevent user code from exploiting uarch bugs. Lucet specifically does not mitigate spectre variant 2.
- feanaro 6y ago
  seccomp escapes are a thing and if you're inside a restrictive environment such as WASM, it is harder to achieve it.
  - CyberRabbi 6y ago
    I think you’re referring to seccomp-bpf. seccomp has never been escaped and it is unlikely such a bug could happen due its simplicity. If you do not know the difference between seccomp and seccomp-bpf, please check references: https://en.wikipedia.org/wiki/Seccomp https://en.wikipedia.org/wiki/Seccomp