On Wed, Oct 26, 2016 at 03:34:50PM +0100, David Howells wrote: > Andy Lutomirski <luto@xxxxxxxxxxxxxx> 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.
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/containers
