[CRIU] Hardening the criu service daemon

[Florian Weimer]

On 09/11/2015 06:43 PM, 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.
>>
>> * 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.
> 
> Florian, since these two CVE exists in suid-ed CRIU also, what's the
> way these two should be handled? If we deprecate service daemon and
> replace it with the mentioned swrk-mode of CRIU, will these two CVEs
> get closed or will they be renamed to say "suid-ed CRIU is not secure"?

I think SUID mode would have to get a different set of CVEs.  Someone
needs to write up all the known security issues with that mode.

I wasn't aware that this was a upstream-supported configuration, so I
didn't spend time investigating this.  (For us, if a system
administrator adds random SUID bits to binaries, it's not a supported
configuration anymore, and it's obviously quite easy to open up
privilege escalation vectors this way.)

-- 
Florian Weimer / Red Hat Product Security