[CRIU] Hardening the criu service daemon

[Pavel Emelyanov]

On 09/01/2015 12:56 PM, Florian Weimer wrote:
> On 09/01/2015 11:45 AM, Pavel Emelyanov wrote:
>> On 08/25/2015 02:55 PM, Florian Weimer wrote:
>>> This was previously discussed privately, but we agreed to make this
>>> public even before fixes are available, to ensure broadest possible
>>> review of the solution we come up with.
>>>
>>> The service daemon currently has at least two sets of security issues:
>>>
>>> * CVE-2015-5228
>>> https://bugzilla.redhat.com/show_bug.cgi?id=1255782
>>>
>>> The service daemon writes to arbitrary places in the file system.  One
>>> file file (criu.log) is even created with ownership matching that of the
>>> requesting process, which gives a fairly direct privilege escalation
>>> path to full root for any local user.  The dump files themselves have
>>> user-controlled contents, which can likely be exploited as well.
>>
>> You told that you had similar issue in abrtd. Maybe we can poke kernel guys
>> to provide the userspace the way to do some system call on behalf of any 
>> other process? Of course, only allowed for root or those having ptrace_may_access
>> ability.
> 
> The challenge is to obtain a stable identifier for that other process.
> In the abrt crash dumper, this is easy because the process is in a
> zombie-like state, and its PID cannot be reused until the crash dumper
> completes, and the associated UIDs will not change, either.  I don't
> think this is true for a client process requesting services from the
> criu daemon.
> 
>> Well, we (in theory) can _make_ another process do what we want using the
>> parasite code injection technique. CRIU already does this on the process it
>> dumps, it can also do the same on the process that requests the dump. This
>> would be heavier version of the above suggestion :)
> 
> You'd still need something stronger than a PID to attach to the process
> (the requester process).

A /proc/pid/something file can be such. Once open()-ed it will pin the struct pid,
so openat(that_fd, "path") will be able to access the original process safely.

>>> The file creation issue could also be fixed by having the requesting
>>> process create the files and pass file descriptors to the dumping
>>> process (or pass all data over the socket).  The kernel ptrace policy
>>> enforcement could be emulated in user space.  These approaches are quite
>>> brittle and dependent on specific security modules, I think.
>>>
>>>
>>> The value of the long-running service daemon is not completely clear to
>>> me.  Maybe it would be better to spawn a service on demand from libcriu?
>>
>> The service appeared from the fact that non-root couldn't access many crucial
>> for dump kernel APIs even for self. So we spawned a service with root caps
>> and ask one for help. Later there appeared the so called "swrk mode". This
>> is when you fork() + exec() CRIU and feed RPC commands into it as to a service.
>> Provided criu binary is suid-ed it works exactly the same as service, so
>> yes, standalone service is pretty much obsoleted by this.
>>
>> But the question is -- does suid-ed criu suffer from the same set of CVE-s?
> 
> Oh.  I had no idea anyone would assume it's safe to install the criu
> command SUID-anything.
> 
> I think so.  It seems even worse because of the scripts interface, which
> is apparently not disabled in the SUID case, only for the daemon.

When you work in swrk mode scripts are not used, regular RPC notifications are.
But you're right, suid criu _can_ be launched in pure CLI mode and this is bad :(

-- Pavel