[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <874mmo54ll.fsf@x220.int.ebiederm.org>
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
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
