From: David Howells <dhowells@redhat.com>
In-Reply-To: <Pine.LNX.4.44.0308221044470.20736-100000@home.osdl.org> 
References: <Pine.LNX.4.44.0308221044470.20736-100000@home.osdl.org> 
To: Linus Torvalds <torvalds@osdl.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: authentication / encryption key retention 
User-Agent: EMH/1.14.1 SEMI/1.14.4 (Hosorogi) FLIM/1.14.4
 (=?ISO-8859-4?Q?Kashiharajing=FE-mae?=) APEL/10.4 Emacs/21.2
 (i386-redhat-linux-gnu) MULE/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi")
Content-Type: text/plain; charset=US-ASCII
Date: Tue, 26 Aug 2003 11:12:54 +0100
Message-ID: <11490.1061892774@redhat.com>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 4689
Lines: 112


So each process should have three keyrings:

	- Process level (inherited over fork/exec, but not SUID)
	- UID level (fixed to whichever UID a process currently is)
	- GID level (fixed to whichever GID a process currently is)

So the search would proceed through the above list top-down, depth first (each
key can itself be another keyring).

But what about:

	- setuid() and related UID syscalls?
	- setgid() and related GID syscalls?
	- SGID programs?
	- The GROUPS list? Each GID there could have a keyring...

I think changes to UID should cause the process level keyring to be exchanged
for a new empty one, but changes in GID/GROUPS should not. Also I think GROUPS
list specified keyrings can be ignored for now.

> No, usually it would just search the keyring, and increment the reference
> count for the key it finds

If your subset is but a single pre-existing key (where this includes a keyring
as a specialisation of a key), then yes; but if the filesystem is permitted to
select multiple keys from different sources, then no.

I think for the moment, however, we can assume there will be a single key.

> Yes, but those filesystems will NOT use the "extended key" functionality 
> at all.

Fair enough.

> Purists go "hey, that's having two totally different mechanisms for the 
> same thing - security". But sane people go "why complicate the issue 
> unnecessarily".

Because not doing so complicates things in other ways. But don't lets worry
about that.

> But some parts of the kernel might look at only the process-local keys 
> ("does this process have rights to do that?")

Why? If a process has access to appropriate UID-level or GID-level keys, then
surely it has the rights to do "that", even if it hasn't copied them into its
process level keyring...

> > The problem with that is you can't pass a subset, only a complete
> > set. Hmmm... I think it ought to be possible to filter on description, but
> > that the data should not ever return to userspace.
> 
> No, you can certainly pass subsets too, by just having a "create a new 
> bucket that contains these other buckets" (which you got from the lookup 
> operation). You never see what the actual keys are, but each bucket and 
> each key do have an ID field, so you can create buckets by reference that 
> way.

Hmmm... if I'm using these keys for AFS, say, then I don't want to have to
search a complete tree of keyrings every time I perform secure operation
(every RxRPC operation possibly). I would like to have the applicable keys
immediately to hand - and only those keys - with as little structure as
possible.

> > I think an ACL is a must (as I've said before). The ACL should provide the
> > following rights:
> 
> Who not just make ACL's part of the "bucket of keys", but make them
> basically "conditional keys" (in the "type field", the same way we
> distinguish between buckets and keys). A conditional key is a key in
> itself, but it's a requirement thing: you can do this operation on the
> tree of keys only if you also have access to the non-conditional version
> of this key.

Um. I'm not sure that what you describe is of much use... I'm not sure I
understand correctly what your suggestion is. Can you give an example please?

> I think it would be a mistake to have _another_ level of keys/ACL's just
> to keep track of what keys you can modify. "Quid custodiet ipsos
> custodies?". Where would it end?

Exactly there. The ACL would contain a right to (dis)allow modifications to
itself.

Actually, it's more a problem of controlling subscription to arbitrarily
subscribable "named" keys.

For example, say that a process (owned by dwmw2) says "give me access to the
keyring named 'dhowells-session-1275'", then what's to prohibit it from
gaining access to all my keys _unless_ I can add an ACL?

Of course, access control could also be performed UID/GID and mode_t settings,
but that's just a very simple ACL.

> Having the tree-of-keys have branches that can be conditional on another 
> key solves the problem. It would be a "you can only add this keyring to 
> your tree if you already have that other key" kind of thing. All 
> self-contained within the architecture.

But how do you get that other key in the first place?

This sounds a lot more complicated than it needs to be, and slow... To perform
subscription, you then have to search the process's three keyrings for a match
for every conditional key in the target tree...

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