[CRIU] checkpointing processes under seccomp restrictions
Tycho Andersen
tycho.andersen at canonical.com
Fri May 8 08:39:06 PDT 2015
On Fri, May 08, 2015 at 06:35:03PM +0300, Pavel Emelyanov wrote:
> On 05/08/2015 06:23 PM, Tycho Andersen wrote:
> > On Fri, May 08, 2015 at 06:18:30PM +0300, Pavel Emelyanov wrote:
> >> On 05/08/2015 06:12 PM, Tycho Andersen wrote:
> >>
> >>>>> In SECCOMP_MODE_FILTER the restricted syscalls are user defined, so it
> >>>>> could be anything.
> >>>>
> >>>> Hm... This sounds promising -- and what's the way to change this mode for
> >>>> a running process?
> >>>
> >>> prctl(PR_SET_SECCOMP, ...);
> >>
> >> Ah. And there's even the separate sys_seccomp() syscall for that.
> >>
> >>> There is currently no way to remove SECCOMP filters, so multiple calls
> >>> to prctl() are cumulative.
> >>
> >> I see. And which is worse, it only works on the calling task, i.e. we will
> >> not be able to turn off or modify the seccomp "from the outside".
> >>
> >> So we have to patch the kernel. I don't know which way the community would
> >> prefer, but I personally would try to start with the ptrace() command that
> >> would temporarily (till ptrace detach) turn the seccomp mode off on the task
> >> under trace.
> >
> > Ah, that is interesting, thanks. I'm ignorant here: is there precedent
> > in ptrace for commands that can only be run from privileged processes
> > in the init user namespace?
>
> Nope (as far as I know) :)
>
> > Since SECCOMP is for protecting the
> > kernel, it is only safe for someone who is "really" root to disable
> > it.
>
> Yes, absolutely. But that's common for C/R kernel patches :) We have (had) quite
> a lot of strict capabilities checks in the interfaces we added.
Great, thanks! Hopefully more on this soon...
Tycho
> -- Pavel
>
More information about the CRIU
mailing list