[CRIU] Hardening the criu service daemon

[Florian Weimer]

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.

* 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).

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?

-- 
Florian Weimer / Red Hat Product Security