lkml.org 
[lkml]   [2004]   [Jun]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: In-kernel Authentication Tokens (PAGs)
Date

> 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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:03    [W:0.181 / U:0.276 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site