The implementation is better than OS X, because OS X has a ton of kernel API surface available to userland and much of it can't even be sandboxed, while tame starts with one syscall and works its way up.
I agree it's not better than seccomp-bpf plus a library to supply these kinds of common policies in userland, with the caveat that I don't know of any such library in common use on Linux.
Yeah, seatbelt is not that compelling in practice, but that's true of the OS X kernel/userspace boundary in general. :/ But the design of it seems to match what's wanted here, exactly: you can enable restrictions during the running of a process, and OS X ships with a handful of standard seatbelt profiles.
pcwalton's gaol, which has both seccomp-bpf and seatbelt backends, has a concept of "profiles," which I think matches the general idea here:
I don't think it would be particularly useful. The most common usage of seccomp is hardening an existing sandbox by reducing kernel attack surface. Fine-grained control is crucial for that, since it's the entire point. Every unnecessary system call or permitted system call flag is added attack surface.
When seccomp is actually being used to implement the sandbox semantics, the application usually needs to be designed around it. It's very difficult to apply it this way to an existing application. I just don't think there's a strong use case for coarse control when it's so far from being the real hard problem.
I agree it's not better than seccomp-bpf plus a library to supply these kinds of common policies in userland, with the caveat that I don't know of any such library in common use on Linux.