On Tue, Oct 25, 2016 at 11:05:08AM -0700, James Bottomley wrote: > On Tue, 2016-10-25 at 19:06 +0200, Jann Horn wrote: > > On Tue, Oct 25, 2016 at 09:56:45AM -0700, James Bottomley wrote: > > > On Tue, 2016-10-25 at 17:53 +0100, David Howells wrote: > > > > David Howells <dhowells@xxxxxxxxxx> wrote: > > > > > > > > > (2) If a process's user_namespace doesn't match that recorded > > > > > in a > > > > > key then > > > > > it gets ENOKEY if it tries to refer to it or access it and > > > > > can't see it > > > > > in /proc/keys. > > > > > > > > There's another possibility here - since user_namespaces are > > > > hierarchical, does it make sense to let a process see keys that > > > > are > > > > in an ancestral namespace? > > > > > > I think that should be the decision of the owner. If you're > > > creating a > > > userns to de-privilege the next user, likely you don't want this, > > > but > > > if you're creating a userns to enhance it, then you do. > > > > > > I think you want to behave exactly as the mount namespace does: on > > > initial clone, you get a fully cloned mount tree and then you > > > customise > > > it by unmounting pieces. > > > > The issue with keys is that their interface is pretty broken when > > exposed to user namespaces with different UID mappings, and this also > > causes security issues where you can get access to other users' > > keyrings and stuff like that. The proposed fix works around that > > brokenness by simply never exposing keys to other namespaces. > > Define how ... we can fix the keyring interface if it's hugely > problematic. See http://lkml.iu.edu/hypermail/linux/kernel/1606.2/06794.html . Here's a copy of my explanation in that message: | 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. | This ends up permitting the attacker to dump the contents of KUID | 1000's keys after KUID 1000 signs in. I discovered this while going | through the kuid->uid conversions when I thought about writing this | feature the first time. > If you're simply thinking that it's a uid range mapping leak, then the > way I think of this is the same way the shadow utils do: the owning > user owns the exterior range of ids. This seems to be the assumption > the unprivileged container systems are working on as well, so it > doesn't matter that there's a theoretical uid leak to the exterior > mapped ids. Nope, that's not the issue. _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/containers
