Keyrings, user namespaces and the user_struct

Jann Horn jann at thejh.net
Wed Oct 26 14:38:56 UTC 2016


On Wed, Oct 26, 2016 at 03:34:50PM +0100, David Howells wrote:
> Andy Lutomirski <luto at amacapital.net> wrote:
> 
> > > | Not just questionable, completely wrong. The gist is that there is a
> > > | *global* name -> key mapping for accessing keys by name, and user
> > > | keyrings are stored in there under the name "_uid.%u", where %u
> > > | refers to the *namespaced* UID. (See install_user_keyrings().)
> > > | The result is that, if e.g. the user with UID 1000 has no running
> > > | processes, a local attacker can enter a new user namespace, map UID
> > > | 1000 in the namespace to some KUID he controls, do
> > > | setresuid(1000, 1000, 1000), and now he owns user 1000's keyring.
> 
> Hmmm...  Having checked over the code, it might not be that simple.  Thanks to
> something Eric Biederman added into find_keyring_by_name(), unless a keyring's
> UID is a member of the current user namespace, you can't find that keyring by
> name.

find_keyring_by_name() checks that the UID of the keyring's owner is mapped into
the current user namespace. But that doesn't catch the scenario I described:
The keyring is created in an attacker-created namespace and looked up from the
init namespace, into which all kuids are mapped.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/containers/attachments/20161026/7b464444/attachment.sig>


More information about the Containers mailing list