5 ms·

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 j

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?
      - CyberRabbi 6y ago
        Whether or not people who likely have no actual experience in this space dislike what I’m saying about the pointlessness of using wasm for this use case has no bearing on my correctness. Most of them demonstrated they didn’t know the difference between seccomp and seccomp-bpf and there have been no rational counter arguments that hold their weight. Usually downvotes without rational rebuttals are a sign of the OP’s correctness.
        eloff 6y ago
        I mention the downvotes because when you find yourself thinking you're right and everyone is wrong usually it's you that's mistaken. In this case anyone with experience in computer security can tell you multiple layers of defense are always better than one. Seccomp is great, and I think you actually have a point about it, but it's hard to get right without locking out all system calls entirely - and that's hard to do and still run a program, even a barebones C program. With higher level languages it's immediately insufficient.
        CyberRabbi 6y ago
        There’s no need for me to guess if I’m wrong or not, prove to me that I’m wrong. Thus far most replies have confused seccomp for seccomp-bpf. Seccomp locks out every system call except for read, write, exit, and sigreturn. That’s why the extra defense afforded by wasm is superfluous here.
        eloff 6y ago
        You're totally ignoring the parts I called you out on, which I'm tempted to view as a tacit admission you see your position there as indefensible. The trouble is you can't run much in that environment - not even mmap or sbrk to allocate heap memory. It's basically embedded C without even malloc. In reality WASM is a more practical target because many high level languages can compile to it. Or you end up needing seccomp-bpf and now the burden is on you to provide enough functionality to run something without also providing so much to allow a sandbox escape.

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?
    - CyberRabbi 6y ago
      Whether or not people who likely have no actual experience in this space dislike what I’m saying about the pointlessness of using wasm for this use case has no bearing on my correctness. Most of them demonstrated they didn’t know the difference between seccomp and seccomp-bpf and there have been no rational counter arguments that hold their weight. Usually downvotes without rational rebuttals are a sign of the OP’s correctness.
      - eloff 6y ago
        I mention the downvotes because when you find yourself thinking you're right and everyone is wrong usually it's you that's mistaken. In this case anyone with experience in computer security can tell you multiple layers of defense are always better than one. Seccomp is great, and I think you actually have a point about it, but it's hard to get right without locking out all system calls entirely - and that's hard to do and still run a program, even a barebones C program. With higher level languages it's immediately insufficient.
        CyberRabbi 6y ago
        There’s no need for me to guess if I’m wrong or not, prove to me that I’m wrong. Thus far most replies have confused seccomp for seccomp-bpf. Seccomp locks out every system call except for read, write, exit, and sigreturn. That’s why the extra defense afforded by wasm is superfluous here.
        eloff 6y ago
        You're totally ignoring the parts I called you out on, which I'm tempted to view as a tacit admission you see your position there as indefensible. The trouble is you can't run much in that environment - not even mmap or sbrk to allocate heap memory. It's basically embedded C without even malloc. In reality WASM is a more practical target because many high level languages can compile to it. Or you end up needing seccomp-bpf and now the burden is on you to provide enough functionality to run something without also providing so much to allow a sandbox escape.