[Devel] Re: [PATCH 0/3] keys: play nicely with user namespaces

[Serge E. Hallyn]

Quoting David Howells (dhowells at redhat.com):
> Serge E. Hallyn <serue at us.ibm.com> wrote:
> 
> > so here is a first attempt at getting keys and uid namespaces
> > to play nice.  The semantics need some discussion.  As I recall
> > Eric and yourself appeared to agree that some keyrings should
> > be inherited into child user namespaces.
> 
> Ummm...  If keys are effectively a per-user-namespace resource, then they
> can't be shared between namespaces.  We could either duplicate all the keys
> and keyrings, or we could just start afresh.  The latter is certainly the
> easiest.
> 
> > I segragate them cleanly bc that appears to be the simplest thing to do
> > especially given the use of i.e. lookup_by_name("uid.500").
> 
> Sounds reasonable.
> 
> > IMO it shouldn't be a big problem - userspace can always list keys it wants
> > into a file, start a new user namespace, then re-read them out of the
> > tempfile...
> 
> Not so.  You aren't necessarily permitted to read a key - the read function
> has to be supported by the key type for a start, and then you have to pass all
> the security checks.

I guess the question is what sorts of keys would you want a child
user-namespace to inherit (that perhaps it couldn't)?  The primary
ones I can think of are keys for an encrypted fs.  Are there any sorts
of keys X uses?

Anyway if this set of patches does the segration correctly, I can float
a patch on top of these to copy the keyrings.  But should the (automatic
in-kernel) copy then still go through the security checks?  (If not, is
that safe, and if so, is there any advantage?)

Do you have an automated testsuite for the keyrings?  I just played
around with keyctl to test, since there was nothing in ltp.

thanks,
-serge
_______________________________________________
Containers mailing list
Containers at lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers