[CRIU] Hardening the criu service daemon

[Pavel Emelyanov]

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.

> * CVE-2015-5231
> https://bugzilla.redhat.com/show_bug.cgi?id=1256728
> 
> The service daemon disregards security policies regarding non-dumpable
> processes.  This includes the kernel.yama.ptrace_scope=1 setting, but
> also prctrl changes (or changes implied ).  Currently, the enforced
> security restriction is based on UID/GID matching, which is insufficient.
> 
> 
> Both issues would be fixed if the service daemon performed the dumping
> and file writing with the exact privileges of the requesting process.
> This may be difficult to achieve because SO_PEERCRED may not give access
> to security information for kernel security modules (such as the SELinux
> context).

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 :)

But see below for more thoughts on this.

> 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?

-- Pavel