Wow. I can't believe anyone even bothered adding seccomp to libmagic file(1).
... "file sets up its sandbox early and thus has to allow a ton of system calls (including open and write) ... this sandbox is somewhat useless, because it is way too weak."
Conversation
Replying to
Yeah, the seccomp filter in file is beyond useless. I looked into trying to fix it (e.g. using classic seccomp, to allow only I/O on files already open), but it's not trivial. This was from a distro I used to work. I almost used your portable version of the OpenBSD file, but...
1
... couldn't risk breaking anything with subtle differences in output.
Merely enabling seccomp broke things because the allocator in that distro is patched to mprotect() to enable huge pages in some cases, for instance...
2
The way they're using seccomp-bpf only makes sense as kernel attack surface reduction as a secondary layer in a sandbox. It's certainly possible to make a good sandbox directly with seccomp-bpf alone but the software has to be built around a privilege separation model.
1
1
It doesn't really make sense to use the mode 1 seccomp since you can use seccomp-bpf to do the same thing and you don't run into the inability to support malloc (mmap, mprotect, munmap) if needed, threads (if applicable), etc. It can definitely make a proper sandbox alone.
If the software isn't ported to a proper privilege separation design, they need to be using something like namespaces for a semantic layer sandbox with seccomp-bpf as a secondary layer. That's how the Chromium sandbox works, but even then it doesn't allow system calls like open.