Re: In-kernel Authentication Tokens (PAGs)
From: David Howells
Date: Wed Jun 16 2004 - 09:25:02 EST
> 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.
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/