Closed ypid closed 8 years ago
This is definitely something that should be supported. I'm not sure yet how the user interface should look though. Whether seccomp filters should be described in permissions.json
or not...
Support for Seccomp has been released in Docker 1.10 :wink: https://github.com/docker/docker/pull/18780 https://github.com/docker/docker/pull/17989
Excelent! I am a bit surprised, however, that this code is not in libcontainer/runc. That isn't so good... But it's something to work with...
On 02/05/16 20:05, Robin Schneider wrote:
Support for Seccomp has been released in Docker 1.10 :wink: docker/docker#18780 https://github.com/docker/docker/pull/18780 docker/docker#17989 https://github.com/docker/docker/pull/17989
— Reply to this email directly or view it on GitHub https://github.com/subuser-security/subuser/issues/269#issuecomment-180503291.
I actually think that Docker vendors in seccomp support from runc (although I may be misreading this...)
https://github.com/opencontainers/runc/blob/master/libcontainer/seccomp/seccomp_linux.go
Aha, when I glanced at the pull request that added seccomp support to Docker there weren't any changes to the runc code, so I guess that means that runc got the support before Docker proper rather than concurrently...
For now, this is fixed, as Docker now defaults to use seccomp for blocking the 44 least common system calls.
It seems that Docker currently does not support seccomp filters and thus also subuser. Somewhat related to https://github.com/subuser-security/subuser/issues/245 This is pretty bad for sandboxing because most kernel exploits use some obscure syscalls. See also: https://l3net.wordpress.com/2016/01/20/firejail-target-practice-cve-2016-0728/