Re: In-kernel Authentication Tokens (PAGs)

[David Howells]

> One thing that I would very much like to have is the ability to create a new
> shell with a new keyring, such that I can still see and use the old keyring,
> but I can create new keys without modifying the old keyring, even to the
> extent of masking out keys in the old keyring without modifying them for
> other processes.  From my brief glance at your patch, that's not a feature
> you have implemented.

Hmmm... What exactly are you wanting to do? Each task theoretically subscribes
to five keyrings (the group one isn't yet there) in this model; three of which
are transferred across a fork, and four across CLONE_THREAD.

The five keyrings are:

	- Group (associated with primary GID)
	- User (associated with UID)
	- Session (voluntarily discarded)
	- Process (shared between threads in a process)
	- Thread (one per thread)

> I would also like the ability to mark a key as unreadable except by kernel
> threads or processes with CAP_KEYRING.

What do you mean by "unreadable"?

Currently, userspace can't see the data attached to a key. It can only see the
description, and only then through /proc/keys.

> If I can pass key "handles" of some sort over UNIX sockets, then I can also
> pass an unreadable key to a daemon process which uses it to access my files
> until I revoke the key.

I can see what you're getting at.

I think I need to create some more operations:

  (*) Retire/Revoke key

  (*) Add key to another keyring

  (*) Remove key from keyring

  (*) List keyring

  (*) Describe key

  (*) Read key (if not protected)

  (*) Create keyring

I have pondered representing keyspace with some sort of filesystem interface
(using vfs ops to represent the operations), but that could require hardlinked
directories (keyrings) to pull off - either that or symlinks.

Also, there's the problem of security on the operations themselves. How do you
determine what a process is allowed to do?

Either I should only allow access to keys and keyrings to which a process is
subscribed, or I should attach UID/GID/MASK values to every key and keyring.

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