[CRIU] checkpointing processes under seccomp restrictions
Pavel Emelyanov
xemul at parallels.com
Fri May 8 08:35:03 PDT 2015
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.
-- Pavel
More information about the CRIU
mailing list