Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Wed, 6 Jan 2016 17:14:37 +0000
From: Serge Hallyn <serge.hallyn@...ntu.com>
To: oss-security@...ts.openwall.com
Cc: cve-assign@...re.org, john.johansen@...onical.com
Subject: Re: Re: CVE Request: Linux kernel: privilege
 escalation in user namespaces

Quoting Eric W. Biederman (ebiederm@...ssion.com):
> Serge Hallyn <serge.hallyn@...ntu.com> writes:
> 
> > Quoting Eric W. Biederman (ebiederm@...ssion.com):
> >> cve-assign@...re.org writes:
> >> 
> >> > Use CVE-2015-8709 for the issue fixed in the
> >> > https://lkml.org/lkml/2015/12/25/71 post.
> >> >
> >> > (This is not yet available at
> >> > http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/log/kernel/ptrace.c
> >> > and http://marc.info/?l=linux-kernel&m=145118185526359 might be the
> >> > current end of the earlier discussion.)
> >> >
> >> > This issue has been covered in security advisories from one or more
> >> > Linux distributions, e.g.,
> >> >
> >> >>> http://www.ubuntu.com/usn/usn-2847-1
> >> >>> 
> >> >>> Jann Horn discovered a ptrace issue with user namespaces in the Linux
> >> >>> kernel. The namespace owner could potentially exploit this flaw by ptracing
> >> >>> a root owned process entering the user namespace to elevate its privileges
> >> >>> and potentially gain access outside of the namespace.
> >> >>> (http://bugs.launchpad.net/bugs/1527374)
> >> >
> >> >
> >> > There has been some discussion of whether the finding was a
> >> > vulnerability discovery, e.g.,
> >> >
> >> >>>> Date: Fri, 18 Dec 2015 00:07:19 +0100
> >> >>>> From: Jann Horn <jann@...jh.net>
> >> >>>> 
> >> >>>> I'm not sure whether this is CVE-worthy - the user_namespaces
> >> >>>> manpage says "the process has full privileges for operations
> >> >>>> inside the user namespace, but is unprivileged for operations
> >> >>>> outside the namespace". ptrace()ing a process in the
> >> >>>> namespace can reasonably be considered an "operation inside
> >> >>>> the user namespace" ...
> >> >>>> 
> >> >>>> In my opinion, this patch is somewhere between hardening and
> >> >>>> a security feature, but I wouldn't really call it a vuln fix.
> >> >
> >> >
> >> >>>>> Date: Thu, 17 Dec 2015 23:54:03 +0000
> >> >>>>> From: Serge Hallyn <serge.hallyn@...ntu.com>
> >> >>>>> 
> >> >>>>>> ptrace()ing a process in the
> >> >>>>>> namespace can reasonably be considered an "operation inside
> >> >>>>>> the user namespace"
> >> >>>>> 
> >> >>>>> Except by creating a file in the host namespace, you were, as
> >> >>>>> root in the container, able to escape your namespace, right?
> >> >
> >> > We feel that, more generally, the usn-2847-1 mention of "and
> >> > potentially gain access outside of the namespace" is a realistic
> >> > concern.
> >> 
> >> My mind is boggling at some of the logic involved here.
> >> 
> >> There is no potentially gaining access outside of the namespace when it
> >> is access to things that were put inside the namespace.
> >> 
> >> The discussion was about how to make it easier for userspace not to do
> >> stupid things, not how to fix a bug in the kernel.
> >> 
> >> The code we have been discussing most definitely does not make it safe
> >> for a arbitrary root owned processes to call setns and enter a user
> >> namespace with a hostile user namespace root.  You have to close file
> >> descriptors, unmap files and do I don't know what else.  Properly
> >> and safely dropping privileges is a challenging problem.
> >> 
> >> Calling bug because it is possible to use a kernel feature wrong feels
> >> completely inappropriate.
> >
> > I could be wrong but think you are misunderstanding the cve.
> >
> > IIRC the situation was:  if you setns(some-userns); setresgid(0,0);
> > setresuid(0,0); then between the setns and the setuids the container
> > can ptrace your task and do things using the host uids.  That's bad.
> 
> It is a pain but it is perfectly possible to:
> 	/* Mess with caps so the next line does not clear CAP_SYS_ADMIN */
> 	setresuid(container_root_uid, container_root_uid);
> 	setns(some_userns);

That works for root, but not for unprivileged user.

Worth doing when possible though.

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