Hacker News Reader

Comment by CyberRabbi | Hacker News Reader

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

View on HN

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.

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.

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

> 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

> 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

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

Reply on news.ycombinator.com