This doesn't seem particularly better than Linux's seccomp-bpf or OS X's seatbelt. In particular, I don't really understand the complaint about not wanting to write a program, then turning around and writing a system call, running with full privilege on the system, that hardcodes all sorts of things about userspace.
I wish he'd acknowledge and discuss prior, effective work in this space instead of saying things "showed up" and they're "insane". For instance, a direct comparison to either seatbelt or seccomp-bpf would make it clear that the distinction between initialization vs. steady state is well-explored in production systems using this (like sandboxed Chrome renderers) and not novel.
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, this isn't particular new or inspired. It's similar to existing mechanisms which the author pointed out.
Seccomp is really hard to integrate into existing programs, especially if they are monolithic and don't have privilege separation already. You can't narrow down the syscall footprint in complex programs enough to get decent protection unless you already have something along the lines of privilege separation. Third party libraries cause headaches too because their syscall footprint might conflict (now or in the future!) with the main program's seccomp configuration.
Capsicum looks interesting. The challenge with fancy security mechanisms is that many people contributing to the codebase may be unaware or care only about use-cases where fine-grained capabilities aren't needed.
At the end of the day, all these mechanisms can work well but it's best to use them from the start and make them one of the key concerns that all developers know about.
The tame call isn't far from being an extremely coarse version of seccomp. In general, both require splitting up programs into components to implement a sandbox. Otherwise, they're only able to reduce the kernel attack surface for an existing sandbox and not nearly as much as they could if it was split up well. They're both vulnerable to changes in third party libraries and don't have control over filesystem access once those system calls are allowed (it's all or nothing, beyond tame's hard-wired paths).
The main missing feature on Linux is the ability for programs to apply their own path-based MAC policy as seccomp can't be used to do string comparisons and couldn't realistically be extended to offer it. It's one of the main reasons that robust seccomp sandboxes require so much work.
You can almost do it, but you can't whitelist paths. Luckily, none of the hard-wired paths is particularly compelling. With either feature, you end up needing a multi-process architecture as soon as you want to allow access to certain paths in a sandbox. It's just that tame hard-wired a few used by the base system, but they aren't generally useful outside of it.
I wish he'd acknowledge and discuss prior, effective work in this space instead of saying things "showed up" and they're "insane". For instance, a direct comparison to either seatbelt or seccomp-bpf would make it clear that the distinction between initialization vs. steady state is well-explored in production systems using this (like sandboxed Chrome renderers) and not novel.