app-level seccomp isolator

[alban]

It would be nice to have an app-level isolator for filtering syscalls.

It will require a new isolator in the spec: appc/spec#529

Extended BPF should be explored too: https://lwn.net/Articles/603983/

Ideally, systemd could implement a new property "SyscallWhitelist=" in the service unit files and rkt would use that.

[jonboulle]

/cc @mjg59

[alban]

http://www.freedesktop.org/software/systemd/man/systemd.exec.html#SystemCallFilter=

[iaguis]

😁

[jessfraz]

I have a whitelist 😇 do you want help?

[alban]

@jfrazelle sure!

One way to easily try your white list in rkt is to add the SystemCallFilter= parameter in WritePrepareAppTemplate(), near CapabilityBoundingSet=. That would define per-app seccomp rules.

Since the systemd unit file for the app currently uses the "appexec" helper, you will need to allow the syscalls used by appexec, such as chroot, setresuid, setresgid. Does your whitelist allow that? To disallow the syscalls used by the appexec helper, more changes would be needed (either add more code in appexec for seccomp support, or remove appexec completely via #679).

To define per-pod seccomp rules, we would need either changes in systemd-nspawn's setup_seccomp(), or to add SystemCallFilter= in the systemd service file that starts rkt. At a first glance, starting with per-app seccomp rules seems the easiest option.

[alban]

Since the systemd unit file for the app currently uses the "appexec" helper, you will need to allow the syscalls used by appexec, such as chroot, setresuid, setresgid. Does your whitelist allow that? To disallow the syscalls used by the appexec helper, more changes would be needed (either add more code in appexec for seccomp support, or remove appexec completely via #679).

Update on this: @iaguis is working on removing appexec in #2493, so we will not need to write more C code in appexec. Instead, using SystemCallFilter= in WritePrepareAppTemplate() should be enough.

[yifan-gu]

Ref kubernetes/kubernetes#24602

[s-urbaniak]

@jfrazelle any update on this? #2493 is merged in 1.5.0 so are you still up for it?

[philips]

@jfrazelle Ping? If you want to take a swing at this it would be awesome!

[jessfraz]

Sorry yes will do :) working on kubes seccomp PR now then this

On Sunday, May 8, 2016, Brandon Philips notifications@github.com wrote:

@jfrazelle https://github.com/jfrazelle Ping? If you want to take a
swing at this it would be awesome!

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#1614 (comment)

Jessie Frazelle
4096R / D4C4 DD60 0D66 F65A 8EFC 511E 18F3 685C 0022 BFF3
pgp.mit.edu http://pgp.mit.edu/pks/lookup?op=get&search=0x18F3685C0022BFF3

[philips]

@jfrazelle sounds great, looking forward to it!

[jonboulle]

@jfrazelle do you think you'll have any bandwidth to get to this soon? Otherwise we might start working on it as we'd love to see it in our next release. Thanks!

[jessfraz]

ok so sorry, definitely this weekend!

On Fri, May 20, 2016 at 8:52 AM, Jonathan Boulle notifications@github.com
wrote:

@jfrazelle https://github.com/jfrazelle do you think you'll have any
bandwidth to get to this soon? Otherwise we might start working on it as
we'd love to see it in our next release. Thanks!

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#1614 (comment)

Jessie Frazelle
4096R / D4C4 DD60 0D66 F65A 8EFC 511E 18F3 685C 0022 BFF3
pgp.mit.edu http://pgp.mit.edu/pks/lookup?op=get&search=0x18F3685C0022BFF3

[jessfraz]

aaaand no time sorry full time job + life is hard :(

On Fri, May 20, 2016 at 9:23 AM, Jessica Frazelle me@jessfraz.com wrote:

ok so sorry, definitely this weekend!

On Fri, May 20, 2016 at 8:52 AM, Jonathan Boulle <notifications@github.com

wrote:

@jfrazelle https://github.com/jfrazelle do you think you'll have any
bandwidth to get to this soon? Otherwise we might start working on it as
we'd love to see it in our next release. Thanks!

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#1614 (comment)

Jessie Frazelle
4096R / D4C4 DD60 0D66 F65A 8EFC 511E 18F3 685C 0022 BFF3
pgp.mit.edu
http://pgp.mit.edu/pks/lookup?op=get&search=0x18F3685C0022BFF3

Jessie Frazelle
4096R / D4C4 DD60 0D66 F65A 8EFC 511E 18F3 685C 0022 BFF3
pgp.mit.edu http://pgp.mit.edu/pks/lookup?op=get&search=0x18F3685C0022BFF3

[iaguis]

Let's try to get it for the next release.

[lucab]

Initial WIP draft for appc at appc/spec#620

Current appc/spec proposal at appc/spec#621. Slightly reworked since the initial draft to address some concerns related to groups and defaults, I don't expect the proposed spec to change drastically anymore at this point.

[lucab]

rkt PR currently up at #2753. It follows the aggressive path of applying a default whitelist, which can be explicitly opted-out. Still marked as WIP as stage1 seems un-happy about unprivileged pods and seccomp.

[lucab]

Bumped milestone, appc spec update still pending. Current plan is to solve the unprivileged pods issue and land it with default whitelisting in 1.9.0; fallback plan is to merge support first and switch the default once everything is fine.

[djtm]

Would be great if the docker seccomp profile files could be reused.

[lucab]

@djtm yes it will expose (among the others) a docker-like profile. Feel free to take a look at #2753.

[djtm]

Great! looks like it would even work with the kvm stage 1.

[lucab]

Closed via #2753.