Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 17 Dec 2015 23:54:03 +0000
From: Serge Hallyn <serge.hallyn@...ntu.com>
To: oss-security@...ts.openwall.com
Cc: John Johansen <john.johansen@...onical.com>
Subject: Re: Re: CVE Request: Linux kernel: privilege
 escalation in user namespaces

Quoting Jann Horn (jann@...jh.net):
> On Thu, Dec 17, 2015 at 02:39:58PM -0800, John Johansen wrote:
> > I haven't seen CVE request for this one yet so,
> > 
> > Jann Horn reported a privilege escalation in user namespaces to the
> > lkml mailing list
> > 
> > https://lkml.org/lkml/2015/12/12/259
> > 
> > if a root-owned process wants to enter a user
> > namespace for some reason without knowing who owns it and
> > therefore can't change to the namespace owner's uid and gid
> > before entering, as soon as it has entered the namespace,
> > the namespace owner can attach to it via ptrace and thereby
> > gain access to its uid and gid.
> 
> 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", and therefore the manpage kinda implies

Except by creating a file in the host namespace, you were, as
root in the container, able to escape your namespace, right?

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.