Message-ID: <20110223155328.GA21266@peq.hallyn.com>
Date:	Wed, 23 Feb 2011 09:53:29 -0600
From:	"Serge E. Hallyn" <serge.hallyn@...onical.com>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
Cc:	David Howells <dhowells@...hat.com>,
	"Serge E. Hallyn" <serge.hallyn@...onical.com>,
	LSM <linux-security-module@...r.kernel.org>,
	Andrew Morton <akpm@...l.org>,
	James Morris <jmorris@...ei.org>,
	Kees Cook <kees.cook@...onical.com>,
	containers@...ts.linux-foundation.org,
	kernel list <linux-kernel@...r.kernel.org>,
	Alexey Dobriyan <adobriyan@...il.com>,
	Michael Kerrisk <mtk.manpages@...il.com>, xemul@...allels.com
Subject: Re: User namespaces and keys

Quoting Eric W. Biederman (ebiederm@...ssion.com):
> David Howells <dhowells@...hat.com> writes:
> 
> > Serge E. Hallyn <serge@...lyn.com> wrote:
> >
> >> > I guess we need to look at how to mix keys and namespaces again.
> >> 
> >> From strictly kernel pov, at the moment, keys are strictly usable only
> >> by the user in your own user namespace.
> >
> > I'm not sure that's currently completely true.  Key quota maintenance is
> > namespaced, and the key's owner UID/GID belong to that namespace, so that's
> > okay, but:
> >
> >  (*) key_task_permission() does not distinguish UIDs and GIDs from different
> >      namespaces.
> >
> >  (*) A key can be referred to by its serial number, no matter whose namespace
> >      it is in, and will yield up its given UID/GID, even if these aren't
> >      actually meaningful in your namespace.
> >
> >      This means request_key() can successfully upcall at the moment.
> >
> > I wonder if I should make the following changes:
> >
> >  (1) If the key and the accessor are in different user namespaces, then skip
> >      the UID and GID comparisons in key_task_permission().  That means that to
> >      be able to access the key you'd have to possess the key and the key would
> >      have to grant you Possessor access, or the key would have to grant you
> >      Other access.
> >
> >  (2) If the key and someone viewing the key description are in different
> >      namespaces, then indicate that the UID and the GID are -1, irrespective of
> >      the actual values.
> >
> >  (3) When an upcall is attempting to instantiate a key, it is allowed to access
> >      the keys of requestor using the requestor's credentials (UID, GID, groups,
> >      security label).  Ensure that this will be done in the requestor's user
> >      namespace.
> >
> >      Nothing should need to be done here, since search_process_keyrings()
> >      switches to the requestor's creds.
> >
> > Oh, and are security labels user-namespaced?
> 
> Not at this time.  The user namespace as currently merged is little more
> than a place holder for a proper implementation.  Serge is busily
> fleshing out that proper implementation.
> 
> Until we reach the point where all checks that have historically been
> "if (uid1 == uid2)" become "if ((uidns1 == uidns2) && (uid1 == uid2))"
> there will be problems.
> 
> The security labels and probably lsm's in general need to be per user
> namespace but we simply have not gotten that far.  For the short term I
> will be happy when we get a minimally usable user namespace.

Note also that when Eric brought this up at the LSM mini-conf two or three
years ago, there was pretty general, strong objection to the idea.

Like Eric says, I think that'll have to wait.  In the meantime, isolating
user namespace sandboxes (or containers) using simple LSM configurations
is a very good idea.

-serge
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists