Hacker News Reader

Comment by the_mitsuhiko | Hacker News Reader

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

View on HN

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

Reply on news.ycombinator.com