[CRIU] checkpointing processes under seccomp restrictions

[Tycho Andersen]

On Fri, May 08, 2015 at 05:57:37PM +0300, Pavel Emelyanov wrote:
> On 05/08/2015 04:11 AM, Tycho Andersen wrote:
> > Hi all,
> > 
> > This afternoon I started hacking on an example branch [1] to checkpoint
> > and restore processes in SECCOMP_MODE_STRICT (as an example for how
> > things might work if we also wanted to do SECCOMP_MODE_FILTER). It
> > wasn't until I finished it that I realized it can't possibly work.
> > 
> > CRIU injects the parasite code into the process, which makes some
> > syscalls that the process isn't allowed to do in STRICT (and
> > potentially may not be allowed to do in FILTER, depending on how the
> > user has configured things). This kills the process, which is
> > obviously bad :)
> 
> Kills?! Is there a way to fix that?

I don't think so, that's by design of seccomp: if the process makes a
syscall that's not allowed, the kernel SIGKILLs the process.

> > What do we do about this? It seems we have at least two options:
> > 
> > 1. Switch things around so the parasite code isn't required. I suppose
> >    some kernel person NAK'd this earlier, which is why the parasite
> >    code exists.
> 
> I'm afraid this is not an option.

That's sort of what I figured :)

> > 2. Allow a root task in the init ns to un-set a process' seccomp mode
> >    so that we can inject the parasite code successfully.
> > 
> > 3. Some other option that I haven't thought of.
> 
> Do you have the list of actions the process (parasite) is not allowed to do?

In SECCOMP_MODE_STRICT the process is only allowed to do exit,
sigreturn, read, and write (so all fds must already be open). In
SECCOMP_MODE_FILTER the restricted syscalls are user defined, so it
could be anything.

Tycho

> -- Pavel
>