Re: Re: CVE request Linux kernel: ns: user namespaces panic

[ebiederm () xmission com (Eric W. Biederman)]

P J P <ppandit () redhat com> writes:

> +-- On Wed, 3 Jun 2015, cve-assign () mitre org wrote --+
> | We feel that this is best covered by two CVE IDs. The 
> | cd4a40174b71acd021877341684d8bb1dc8ea4ae issue seems to be about lack of 
> | state identification (i.e., the state is whether the path is mounted or 
> | unmounted),
>
>   Not sure if it'd have security implications which an end user could use or 
> trigger. CC'ing upstream author Eric for any clarificaitons.

The core issue is that a unprivileged user could call umount(MNT_DETACH)
and in the right circumstances gain access to every file on essentially
any filesystem in the mount namespace.

So in a kernel with user namespaces enabled and you are running a
sandbox like docker that has a real root user inside.  That root user
could with a little work remove every ro bind mount on top of proc.
Such as /proc/sys/.

Allowing a user that simply has uid 0 and no caps access to do all kinds
of interesting things.

The bug fix modifies umount(MNT_DETACH) to keeps mounts covered
even after the actual umount.  That changes makes it unsafe for
copy_tree to run on an unmounted mount tree because one of it's
assumptions is violated.  Which assumption I do not remember at this
late hour.  But I think it was something bad enough to cause a crash.
I can not recall all of the details when reading through the code
at this late hour.

Previously copy_tree on an unmounted tree would just return a single
struct mount as all of the connections would have been cleanly removed.

So I believe cd4a40174b71acd021877341684d8bb1dc8ea4ae prevents a
difficult to trigger crash if you have
e0c9c0afd2fc958ffa34b697972721d81df8a56f applied.

e0c9c0afd2fc958ffa34b697972721d81df8a56f mnt: Update detach_mounts to leave mounts connected
is the real bug fix that fixes a fairly scary issue.

I hope that helps.

Eric