From: David Howells <dhowells@redhat.com>
To: Linus Torvalds <torvalds@osdl.org>
cc: linux-kernel@vger.kernel.org
Subject: 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: Fri, 22 Aug 2003 16:25:43 +0100
Message-ID: <18281.1061565943@redhat.com>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 3241
Lines: 84


Hi Linus,

I'm looking at implementing authentication token and encryption key retention
for the 2.7 kernel again.

I can implement keyrings and sequences of keyrings, but the problem I'm not
sure about it how to attach them to a process. Are you willing to advise me on
my ideas?

I think the best way is to have a stack of "personae" attached to a
process. Each persona would then have an identity (UID) and a sequence of keys.

Personae would be acquired by way of SUID programs, AF_UNIX credential passing,
and directly by way of syscalls.

The top persona on the stack would define what the process looked like to other
processes - controlling access to the process by signal and ptrace.

One of the personae on the stack would be elected to be the "effective" one -
the one that gets attached to newly opened files, and is used to specify access
to other processes for signal and ptrace.

Syscalls would be provided to reorder and modify the contents of the persona
stack.

Each struct file would have a pointer to the persona that contains the identity
and keys governing access to the underlying data.

Syscalls would also be provided to subscribe a persona to new keyrings (persona
would be shared as long as possible, but would be forked on modification).

Each Keyring would contain a set of distinguishable keys of various types, eg:
UNIX groups list, kerberos TGT for a particular domain, encryption key, process
access key. Each keyring would have an ACL that governs which UIDs/GIDs are
allowed to subscribe to it or modify it. Whilst keyrings would be visible
through sysfs, they would not be persistent once no longer in use.


However, all this makes for a few problems:

 (1) setuid()

     This can be made to manipulate the personae stack in various ways, but
     it'd be hard to get it'd work exactly as before.

     This is especially true with respect to GIDs. I think I'd have to attach
     a GID to each persona, however this would mean these UID manipulating
     syscalls would _also_ manipulate GIDs.

 (2) setreuid(), setresuid()

     As with setuid(), except that these would then manipulate multiple
     personae simultaneously, which probably won't be a problem - except if the
     "effective" UID is not a member of the stack...

     The top two entries on the stack can be viewed as real (TOS) and saved
     (2OS) UIDs.

 (3) setgid()

     GIDs would no longer be independent of UIDs, so this would change the GID
     on both the TOS and the effective persona.

 (4) setregid(), setresgid()

     These give the worst problems. I could duplicate personae to make sure I
     can store all the GIDs if they are all different, but that then has
     consequences for setre*uid().

 (5) setfsuid()

     This would then select the first persona on the stack that matches the
     UID, but what if there is no match? Should it then create a new persona
     with a different UID?

What I don't know is how attached we are to the current interface.

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/