Replies: 1 comment
-
Yes please. This will allow us to handle the case where new syscalls are added to the ABI. Ideally, the default seccomp profile would also be obtainable in json format, to provide an easy starting point for modification. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
System calls allow or disallow certain features to be used from within the container.
The limitations are enforced by the kernel via means of (lib)seccomp besides others.
Commonly seccomp rules are enforced by the client i.e. as docker does.
For the concourse case, the concourse worker is in that sense the client and provides these to allow,
i.e.
ptrace
attach for certain performance / fuzzing tools or allowing system calls to handle specific devices.Currently this is hardcoded in https://github.com/concourse/concourse/blob/8c8eb0565101b287107fe9d36ef970505ad166b7/worker/runtime/spec/seccomp.go
The idea would be to make it configurable instead with a json based format as is the norm with seccomp profiles.
If one is already at it, the same things could (should?) be done for
https://github.com/concourse/concourse/blob/8c8eb0565101b287107fe9d36ef970505ad166b7/worker/runtime/spec/devices.go
https://github.com/concourse/concourse/blob/8c8eb0565101b287107fe9d36ef970505ad166b7/worker/runtime/spec/capabilities.go
This is especially true since there is a bit of 🪆 - in the above case, it's not a seccomp rules, but a capability that prevented the execution.
Likely related:
valgrind does not work #6859
Vaguely related:
oci hooks #6535
Beta Was this translation helpful? Give feedback.
All reactions