Re: CVE-2019-5736: runc container breakout (all versions)

[Aleksa Sarai <cyphar () cyphar com>]

On 2019-02-12, Steve Grubb <sgrubb () redhat com> wrote:
> On Tuesday, February 12, 2019 8:55:18 AM EST Florian Weimer wrote:
> > * Aleksa Sarai:
> > > + memfd = memfd_create(MEMFD_COMMENT, MFD_CLOEXEC|MFD_ALLOW_SEALING);
> > > + if (memfd < 0)
> > > +         goto err_binfd;
> >
> > Is it really necessary to use a memfd_create here?  Do you really need
> > sealing?  It's a bit odd to add a new system call dependency in a
> > security update.
>
> That's along the lines of what I was thinking also. This looks like more of a 
> workaround than a root cause fix. Without seeing the exploit or a full 
> discussion of the theory of operation, we really can't pinpoint where the 
> issue is. Was it because of CAP_DAC_OVERRIDE? Is there a missing permission 
> check crossing a trust boundary? Was excessive permissions requested in a 
> syscall? Given the patch, we can sort of see what the issue is but not the 
> exact issue.

It's not because of CAP_DAC_OVERRIDE. It's just regular DAC. As for it
not being a root cause fix, I disagree (it protects against a variety of
concerning attacks that aren't related to this CVE). Obviously if
everyone used correctly-configured user namespaces then this wouldn't be
a problem -- but here were are.

But if you would like an even better fix there is the O_THISROOT
patchset[1] which I'm going to re-send tomorrow and would help fix this
and could help fix a wide variety of other container runtime issues that
have been bothering me for a couple of years. :P

[1]: https://lwn.net/Articles/767547/

-- 
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
<https://www.cyphar.com/>

Attachment: signature.asc
Description: