[CRIU] Hardening the criu service daemon

[Cyrill Gorcunov]

On Tue, Aug 25, 2015 at 01:55:38PM +0200, 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.
> 
> * 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?

I suspect the main problem comes from ability to run user-supplied
scripts, right?

Some actions on dump require sys-admin privilegues unfortunately so
we can't just drop this requirement. Still we definitely need to
somehow limit criu requirements. Thanks for noticing!

Pavel, Andrew, any ideas?