Initial code

[alban]

Demo of a Seccomp Agent that is able to handle a few syscalls on behalf of the container:

• mount(): mount a new procfs in the container namespaces
• mkdir(): changing the path depending on the container
• execve(): adding a delay on some programs

It can be deployed in Kubernetes with:

kubectl apply -f deploy/seccompagent.yaml

cc @mauriciovasquezbernal @iaguis

[rata]

I don't think this applies now as mount/mkdir can't return EINTR, but this is so scary that I want to point it out somewhere (should we create an issue?). A few minutes ago these emails were sent clarifying the seccomp_user_notif(2) manpage: https://lists.linuxfoundation.org/pipermail/containers/2020-November/042585.html https://lists.linuxfoundation.org/pipermail/containers/2020-November/042586.html

When implementing a generic logic to block on some syscalls (like to handle accept() for the target), if we don't remember this I guess debugging can be really painful.

Alban, let me know if this goes better in an issue or if this affects the current code (my guess is it doesn't, but haven't looked).

[alban]

[EINTR] Alban, let me know if this goes better in an issue or if this affects the current code (my guess is it doesn't, but haven't looked).

For mkdir and mount, it seems fine, but I don't know how to handle that properly in the general case... what happens if the target process was interrupted with EINTR but the seccomp agent has already done the action on behalf of the container. Can it cancel the action in a generic way? The target process would probably try again when it receives EINTR, but then the seccomp agent would run the action twice...