[RFC] Introduce support for syscall filtering in containers by mheon · Pull Request #237 · docker-archive/libcontainer

mheon · 2014-10-24T18:21:41Z

This PR introduces the ability to filter system calls on a per-container basis on Linux, using libseccomp to support multiple architectures.

This adds another layer of security between containers and the kernel. System calls which are unnecessary in a container or problematic from a security perspective can be restricted to prevent their use. Most of the truly problematic syscalls are already restricted by dropping capabilities; this adds an additional, finer-grained layer of protection.

There's a similar feature present in LXC already, with the significant difference that LXC uses a whitelist of system calls, whereas these patches use a blacklist. The blacklist approach ensures no difference in functionality to clients not explicitly aware of seccomp support (the restricted syscalls list in the container config is left empty, and the seccomp init function exits without taking action).

This PR adds a vendored library dependency (Go bindings for libseccomp) and a build dependency on libseccomp >= v2.1. The actual changes to libcontainer are fairly minimal, most of the delta is in the libseccomp bindings.

Presently missing: integration tests, documentation

crosbymichael · 2014-10-24T18:22:27Z

@tianon for the dep

This looks cool

mrunalp · 2014-10-24T18:28:49Z

@mheon Some files need gofmt. See Travis.

rhatdan · 2014-10-24T18:30:51Z

We are looking to block certain syscalls, as well as a much wider group like 32 bit syscalls.
By turning on this feature we can greatly shrink the attack surface of the kernel.

  container.RestrictSyscalls = []string{"kexec_load", "open_by_handle_at", "init_module", "finit_module", "delete_module", "iopl", "ioperm", "swapon", "swapoff", "sysfs", "sysctl", "adjtimex", "clock_adjtime", "lookup_dcookie", "perf_event_open", "fanotify_init", "kcmp"}

This is the current list we would block.

http://sourceforge.net/projects/libseccomp/

This patch is not ready for pulling
https://github.com/rhatdan/docker/tree/seccomp
but gives you an idea of the interface we might use for docker

docker run --security_opt seccomp:add:SYSCALL --security_opt:seccomp:remove:SYSCALL
...

crosbymichael · 2014-10-24T18:31:41Z

Can you also add some sample configs so that we can test and view these changes in libcontainer?

vmarmol · 2014-10-24T19:55:34Z

Very cool! +1 to seccomp support :)

crosbymichael · 2014-10-24T20:31:32Z

Travis is failing because of the libseccomp dep.

crosbymichael · 2014-10-24T20:42:56Z

@mheon I think this is a no-brainer to merge. If you get an integration test (maybe some docs ) and figure out the travis issue we can merge it asap. Thanks a lot!

tianon · 2014-10-24T20:56:54Z

New dep seems alright to me! It'd be sweet if we could convince upstream there to use some version tags or something, but clearly not a dealbreaker.

rjnagal · 2014-10-24T23:35:12Z

+1. Thanks @mheon, this is really cool.

On Fri, Oct 24, 2014 at 1:56 PM, Tianon Gravi notifications@github.com
wrote:

New dep seems alright to me! It'd be sweet if we could convince upstream
there to use some version tags or something, but clearly not a dealbreaker.

—
Reply to this email directly or view it on GitHub
#237 (comment).

mrunalp · 2014-10-29T16:49:47Z

make direct-build fails in travis because the libseccomp dependencies aren't installed there. Is there any way to work around this @tianon ?

Vendored golang-seccomp bindings for libseccomp added, as is a build dependency on libseccomp version 2.1 or higher. Signed-off-by: Matthew Heon <mheon@redhat.com>

mheon · 2014-10-29T16:59:59Z

Added a few integration tests. Hard to create good ones as Busybox doesn't check for unusual error codes on a lot of common syscalls, which is the deny mechanism used here (return EPERM).

This won't fix the Travis issue, though I'll defer to @tianon on the preferred fix there. Docker seems to just remove problematic tests, but it should also be possible to install the dependencies to make them run?

tianon · 2014-10-31T06:51:51Z

I think we've just been using testing.Short or whatever it is to skip the
tests Travis can't run; check some of the networking tests, I think they do
this.

mrunalp · 2014-10-31T17:25:29Z

That takes care of the tests, but the build still fails unless we introduce a build tag. I am on the fence for that but don't see any options if we want to make travis pass short of modifying the image to install those dependencies. @crosbymichael @tianon Any thoughts?

rhatdan · 2014-10-31T18:30:17Z

I think you need build flags, because some platforms might not support seccomp.

mrunalp · 2014-10-31T19:32:51Z

@rhatdan Yes, platform tags are definitely required. The other dimension here is we can't add/install libseccomp packages to the travis image, so would also have to use a seccomp tag (like selinux) to make the build pass.

tianon · 2014-11-04T21:56:21Z

Indeed, I agree that build tags seem like the only real path forward here.

cyphar · 2014-11-06T17:07:55Z

+1 for libseccomp support. One security hardening at a time. 😄

This PR introduces the ability to filter system calls on a per-container basis on Linux, using libseccomp to support multiple architectures. This adds another layer of security between containers and the kernel. System calls which are unnecessary in a container or problematic from a security perspective can be restricted to prevent their use. Most of the truly problematic syscalls are already restricted by dropping capabilities; this adds an additional, finer-grained layer of protection. There's a similar feature present in LXC already, with the significant difference that LXC uses a whitelist of system calls, whereas these patches use a blacklist. The blacklist approach ensures no difference in functionality to clients not explicitly aware of seccomp support (the restricted syscalls list in the container config is left empty, and the seccomp init function exits without taking action). This PR adds a vendored library dependency (Go bindings for libseccomp) and a build dependency on libseccomp >= v2.1. The actual changes to libcontainer are fairly minimal, most of the delta is in the libseccomp bindings. Presently missing: integration tests, documentation Docker-DCO-1.1-Signed-off-by: Dan Walsh <dwalsh@redhat.com> (github: rhatdan)

This PR introduces the ability to filter system calls on a per-container basis on Linux, using libseccomp to support multiple architectures. This adds another layer of security between containers and the kernel. System calls which are unnecessary in a container or problematic from a security perspective can be restricted to prevent their use. Most of the truly problematic syscalls are already restricted by dropping capabilities; this adds an additional, finer-grained layer of protection. There's a similar feature present in LXC already, with the significant difference that LXC uses a whitelist of system calls, whereas these patches use a blacklist. The blacklist approach ensures no difference in functionality to clients not explicitly aware of seccomp support (the restricted syscalls list in the container config is left empty, and the seccomp init function exits without taking action). This PR adds a vendored library dependency (Go bindings for libseccomp) and a build dependency on libseccomp >= v2.1. The actual changes to libcontainer are fairly minimal, most of the delta is in the libseccomp bindings. Presently missing: integration tests, documentation Docker-DCO-1.1-Signed-off-by: Matt Heon <mheon@redhat.com> (github: mheon) Docker-DCO-1.1-Signed-off-by: Dan Walsh <dwalsh@redhat.com> (github: rhatdan)

mrunalp · 2014-11-15T05:54:19Z

Closing in favor of #263

This PR introduces the ability to filter system calls on a per-container basis on Linux, using libseccomp to support multiple architectures. This adds another layer of security between containers and the kernel. System calls which are unnecessary in a container or problematic from a security perspective can be restricted to prevent their use. Most of the truly problematic syscalls are already restricted by dropping capabilities; this adds an additional, finer-grained layer of protection. There's a similar feature present in LXC already, with the significant difference that LXC uses a whitelist of system calls, whereas these patches use a blacklist. The blacklist approach ensures no difference in functionality to clients not explicitly aware of seccomp support (the restricted syscalls list in the container config is left empty, and the seccomp init function exits without taking action). This PR adds a vendored library dependency (Go bindings for libseccomp) and a build dependency on libseccomp >= v2.1. The actual changes to libcontainer are fairly minimal, most of the delta is in the libseccomp bindings. Presently missing: integration tests, documentation Docker-DCO-1.1-Signed-off-by: Matt Heon <mheon@redhat.com> (github: mheon) Docker-DCO-1.1-Signed-off-by: Dan Walsh <dwalsh@redhat.com> (github: rhatdan)

This PR introduces the ability to filter system calls on a per-container basis on Linux, using libseccomp to support multiple architectures. This adds another layer of security between containers and the kernel. System calls which are unnecessary in a container or problematic from a security perspective can be restricted to prevent their use. Most of the truly problematic syscalls are already restricted by dropping capabilities; this adds an additional, finer-grained layer of protection. There's a similar feature present in LXC already, with the significant difference that LXC uses a whitelist of system calls, whereas these patches use a blacklist. The blacklist approach ensures no difference in functionality to clients not explicitly aware of seccomp support (the restricted syscalls list in the container config is left empty, and the seccomp init function exits without taking action). This PR adds a vendored library dependency (Go bindings for libseccomp) and a build dependency on libseccomp >= v2.1. The actual changes to libcontainer are fairly minimal, most of the delta is in the libseccomp bindings. Presently missing: integration tests, documentation Docker-DCO-1.1-Signed-off-by: Matt Heon <mheon@redhat.com> (github: mheon) Docker-DCO-1.1-Signed-off-by: Dan Walsh <dwalsh@redhat.com> (github: rhatdan) Conflicts: config.go

This PR introduces the ability to filter system calls on a per-container basis on Linux, using libseccomp to support multiple architectures. This adds another layer of security between containers and the kernel. System calls which are unnecessary in a container or problematic from a security perspective can be restricted to prevent their use. Most of the truly problematic syscalls are already restricted by dropping capabilities; this adds an additional, finer-grained layer of protection. There's a similar feature present in LXC already, with the significant difference that LXC uses a whitelist of system calls, whereas these patches use a blacklist. The blacklist approach ensures no difference in functionality to clients not explicitly aware of seccomp support (the restricted syscalls list in the container config is left empty, and the seccomp init function exits without taking action). This PR adds a vendored library dependency (Go bindings for libseccomp) and a build dependency on libseccomp >= v2.1. The actual changes to libcontainer are fairly minimal, most of the delta is in the libseccomp bindings. Docker-DCO-1.1-Signed-off-by: Dan Walsh <dwalsh@redhat.com> (github: rhatdan) Docker-DCO-1.1-Signed-off-by: Matt Heon <mheon@redhat.com> (github: mheon)

This PR introduces the ability to filter system calls on a per-container basis on Linux, using libseccomp to support multiple architectures. This adds another layer of security between containers and the kernel. System calls which are unnecessary in a container or problematic from a security perspective can be restricted to prevent their use. Most of the truly problematic syscalls are already restricted by dropping capabilities; this adds an additional, finer-grained layer of protection. There's a similar feature present in LXC already, with the significant difference that LXC uses a whitelist of system calls, whereas these patches use a blacklist. The blacklist approach ensures no difference in functionality to clients not aware of seccomp support. This PR adds a vendored library dependency (Go bindings for libseccomp) and a build dependency on libseccomp >= v2.1. The actual changes to libcontainer are fairly minimal, most of the delta is in the libseccomp bindings. Docker-DCO-1.1-Signed-off-by: Dan Walsh <dwalsh@redhat.com> (github: rhatdan) Docker-DCO-1.1-Signed-off-by: Matt Heon <mheon@redhat.com> (github: mheon)

This PR introduces the ability to filter system calls on a per-container basis on Linux, using libseccomp to support multiple architectures. This adds another layer of security between containers and the kernel. System calls which are unnecessary in a container or problematic from a security perspective can be restricted to prevent their use. Most of the truly problematic syscalls are already restricted by dropping capabilities; this adds an additional, finer-grained layer of protection. This PR adds a vendored library dependency (Go bindings for libseccomp) and a build dependency on libseccomp >= v2.1. The actual changes to libcontainer are fairly minimal, most of the delta is in the libseccomp bindings. Docker-DCO-1.1-Signed-off-by: Dan Walsh <dwalsh@redhat.com> (github: rhatdan) Docker-DCO-1.1-Signed-off-by: Matt Heon <mheon@redhat.com> (github: mheon)

mheon force-pushed the seccomp branch from 270a46c to 64d289b Compare October 24, 2014 18:34

gdm85 mentioned this pull request Oct 27, 2014

sysctl tunables moby/moby#4717

Closed

Added support for Libseccomp syscall filtering

f643458

Vendored golang-seccomp bindings for libseccomp added, as is a build dependency on libseccomp version 2.1 or higher. Signed-off-by: Matthew Heon <mheon@redhat.com>

mheon force-pushed the seccomp branch from 64d289b to f643458 Compare October 29, 2014 16:56

rhatdan mentioned this pull request Nov 14, 2014

Introduce support for syscall filtering in containers #263

Closed

mrunalp closed this Nov 15, 2014

Conversation

mheon commented Oct 24, 2014

Uh oh!

crosbymichael commented Oct 24, 2014

Uh oh!

mrunalp commented Oct 24, 2014

Uh oh!

rhatdan commented Oct 24, 2014

Uh oh!

crosbymichael commented Oct 24, 2014

Uh oh!

vmarmol commented Oct 24, 2014

Uh oh!

crosbymichael commented Oct 24, 2014

Uh oh!

crosbymichael commented Oct 24, 2014

Uh oh!

tianon commented Oct 24, 2014

Uh oh!

rjnagal commented Oct 24, 2014

Uh oh!

mrunalp commented Oct 29, 2014

Uh oh!

mheon commented Oct 29, 2014

Uh oh!

tianon commented Oct 31, 2014

Uh oh!

mrunalp commented Oct 31, 2014

Uh oh!

rhatdan commented Oct 31, 2014

Uh oh!

mrunalp commented Oct 31, 2014

Uh oh!

tianon commented Nov 4, 2014

Uh oh!

cyphar commented Nov 6, 2014

Uh oh!

mrunalp commented Nov 15, 2014

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

8 participants