Direction for WAR-ing seccomp restrictions in containers

[martinradev]

I have the following usecase:

• Run criu inside a container whose manager (Docker, LXC, etc) apply seccomp filter for the root process
• Seccomp cannot be removed. It's part of the setup.

I think that a direction for this is to allow users to ignore filters at their own demise.

For example: criu ... --ignore-seccomp ... The argument would need to be provided on save and restore.

Problems:

• Application may rely on seccomp rules for correctness.
• Removing seccomp filter on restore can cause security issues.

Benefits:

• criu works in default docker and lxc configurations

[martinradev]

I'm looking for the right architectural solution to support my usecase. I'm happy to get my hands dirty once direction is agreed.

[adrianreber]

The idea sounds good. My main question is, especially about containers created by Podman and Docker. To use CRIU in one of those containers I am used to start it with --privileged, because it does not work otherwise. Containers started with --privileged are running without seccomp if I remember it correctly.

Are you using CRIU in containers without --privileged and the only problem you are seeing is seccomp related?

[martinradev]

In particular, I don't know how the container is started since I do not own the infra. My guess is that it's started with strict seccomp applied for security.

Thanks for the direction, patches are on me.

[adrianreber]

Are you sure that seccomp is the only thing that blocks you? I would expect there are more problems.

[github-actions[bot]]

A friendly reminder that this issue had no activity for 30 days.