3 ms·

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 exi

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.

strcat 11y ago
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.
- nicm 11y ago
  A few points: - Requiring people to write rulesets or explicitly list syscalls they want is complicated, so barely anyone will use it. We want it to be easy. - tame is for OpenBSD. OpenBSD has many daemons that are already split up into sandboxes, often with common APIs (eg imsg) that use a small set of syscalls. tame will fit into and extend that. Often with relatively few source code changes so far, because we don't have to write lists of syscalls or much special processing. And if major changes are required - it is one project, we can change kernel and userland together. - There has been no suggestion that I have heard that tame be considered a portable API, or something we would like others to adopt. - Why not a library? Well, that was considered, but why not the kernel? There are advantages to both approaches. - There is some talk of changing the way paths are handled, we will see where that goes. It is still early.

strcat 11y ago

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.

nicm 11y ago
A few points: - Requiring people to write rulesets or explicitly list syscalls they want is complicated, so barely anyone will use it. We want it to be easy. - tame is for OpenBSD. OpenBSD has many daemons that are already split up into sandboxes, often with common APIs (eg imsg) that use a small set of syscalls. tame will fit into and extend that. Often with relatively few source code changes so far, because we don't have to write lists of syscalls or much special processing. And if major changes are required - it is one project, we can change kernel and userland together. - There has been no suggestion that I have heard that tame be considered a portable API, or something we would like others to adopt. - Why not a library? Well, that was considered, but why not the kernel? There are advantages to both approaches. - There is some talk of changing the way paths are handled, we will see where that goes. It is still early.