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.

> 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.

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

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.

"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.

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).

By definition a WASM runtime running within seccomp does not increase the attack surface. That's in fact the whole point of layering such systems. I'm not exactly sure what your point is or why you're talking about seccomp-bpf here.

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.

> 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.

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.

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.

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

In a WASM + seccomp implementation, the whole WASM runtime runs inside seccomp. Breaking out of WASM leaves one running arbitrary asm inside seccomp, which has exactly the same attack surface as directly running untrusted binaries inside seccomp. The WASM layer in WASM + seccomp simply requires an additional exploit.

You’re referring to seccomp-bpf, not seccomp. Seccomp-bpf + wasm has a dramatically larger attack surface than just seccomp. Please check references if you do not know the difference between seccomp-bpf and seccomp: https://en.wikipedia.org/wiki/Seccomp

> 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?

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.

>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.

In seccomp the only syscalls available are read, write, exit, and sigreturn. There is nothing to miss

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.

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.

Security by obscurity?

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.

That’s just redundant

Redundancy is sometimes good. When it comes to containing exploits, surely it's better to be safe than sorry.

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.

I don’t think you get the difference between seccomp and seccomp-bpf

You've been downvoted to oblivion. Don't you think that's a sign that maybe you're wrong?

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.

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.

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.

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.

Are you serious? You just allocate a large section of virtual memory before entering seccomp mode. This is not hard. I have used seccomp in production myself.

Not to mention sandboxed wasm is similarly restrictive and you need third-party library support to operate in that “embedded” environment. You don’t just get a normal runtime environment for free. Wasm simply gets you memory “bounds checks” but it’s not necessary if the isolate owns the entire process, as in the seccomp model.

Are you serious? You want to ask partners to write embedded C programs using a pre allocated virtual memory range?

It's obvious why they went for WASM instead.

My point was exactly that you don’t necessarily write your code for an embedded environment in the seccomp model. You provide code in a dynamic library format and the normal dynamic linker links the necessary calls (e.g. malloc) at runtime, exactly as a wasm would provide that environment (via WASI or whatever). Since those calls are all only implemented in terms of write,read,exit,and sigreturn you are guaranteed a high level of security.

Wasm is no different in this regard. You don’t get libc for free with wasm. The only thing you get with a wasm format is memory bounds checking but again that isn’t necessary in the seccomp model.

The big difference is the tooling gives you that for free with WASM. You can even run Go programs in WASM. You don't get that with seccomp.

Exactly, and there is probably a third redundancy too.

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

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.

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/s...

Running code in a wasm vm doesn’t magically prevent user code from exploiting uarch bugs. Lucet specifically does not mitigate spectre variant 2.

seccomp escapes are a thing and if you're inside a restrictive environment such as WASM, it is harder to achieve it.

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

Unlikely? Sounds like you think it could happen.

Nothing is 100%. It’s effectively impossible.

This disproves your point. How many "effectively impossible" exploits have come out recently?

The semantic gymnastics here are pretty interesting. It’s about as secure / impossible to penetrate as anyone could reasonably guarantee in the face of future uncertainty. If you don’t understand why, please check references on how seccomp works: https://en.Wikipedia.org/wiki/Seccomp