linux-kernel - Re: User namespaces and keys

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <m162sasqj6.fsf@fess.ebiederm.org>
Date:	Wed, 23 Feb 2011 07:45:49 -0800
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	David Howells <dhowells@...hat.com>
Cc:	"Serge E. Hallyn" <serge@...lyn.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

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.

Eric
--
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/