Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 04 Jun 2015 02:12:54 -0500
From: ebiederm@...ssion.com (Eric W. Biederman)
To: P J P <ppandit@...hat.com>
Cc: oss security list <oss-security@...ts.openwall.com>,  cve-assign@...re.org
Subject: Re: Re: CVE request Linux kernel: ns: user namespaces panic

P J P <ppandit@...hat.com> writes:

> +-- On Wed, 3 Jun 2015, cve-assign@...re.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

Powered by blists - more mailing lists

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ