Please CC me, I am not on OpenAFS-devel
On Jul 13, 2004, at 11:37, Tomas Olsson wrote:
Hi, on the openafs-devel list, John Bucy wroteIs that correct? What's the plan?In the current proposal which I believe Kyle Moffett is coding up right now, setuid() and co. don't do anything with the keyrings.
The proposal I am working on does not currently need to add additional logic
to any existing sys-calls. It merely associates additional data with certain
contexts:
Thread
Process
Process-Group
Session
UID
GID
Each of these objects will have an additional pointer to a key (A key-ring is just
a special case of a key that has sub-keys). When something (EG OpenAFS),
requires tokens of a particular type for a particular realm, it performs a generic
search using a kernel function. That search looks through each of the above
in order. If a key is a key-ring, first all keys of the specified type are checked,
then all nested key-rings, in arbitrary order.
setuid() et. al. require no additional logic because they just modify UID/GID. If
there are any key-rings associated with the UID/GID, those won't be available
any more and the ones of the new UID/GID will, but that is the only changing
one part of the set. On the other hand, keys that are not linked through the UID
or GID will remain the same without explicit manipulation. This makes it easy
for me to give a setuid program the ability to read in a file from my AFS home.
This has the proviso that SETUID programs should not become insecure if
they discover that they have _less_ privileges than they need, but that kind of
program is inherently insecure anyway.
Cheers, Kyle Moffett
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCM/CS/IT/U d- s++: a17 C++++>$ UB/L/X/*++++(+)>$ P+++(++++)>$
L++++(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+
PGP+++ t+(+++) 5 X R? tv-(--) b++++(++) DI+ D+ G e->++++$ h!*()>++$ r !y?(-)
------END GEEK CODE BLOCK------
Here is my post on the LKML from about a week ago discussing the proposed
system in great detail, in case anyone is interested.
Kyle Moffett wrote:
1) A key-ring is an object independent of what uses it. It supports operations
to read, modify, and search it.
When I refer to a key by name here, I am talking about "[EMAIL PROTECTED]" type
name:
2) When a key-ring is searched for a particular key by name and type, first
it checks all keys of the specified type within said key-ring. If it does not find it
there, then it proceeds with all sub-key-rings.
3) Keys and key-rings are allocated and referenced through an independent
number space (Somewhat like the PID allocator)
There are two namespaces here, a global numerical one (referenced above),
and a per-process file-descriptor one. In order to do operations on a key or
keyring, you must have a file-descriptor to it. The only way to convert a key
id to a file-descriptor is through the "keyfs" file system (see below) which has
whatever permissions are desired. The permissions model is still very much
in flux, if you have any suggestions or questions please contact me.
4) Key and key-ring access should be controlled using permissions and
POSIX ACLs as though they were files. In this case, however, the "execute"
permission bit is used to control in-kernel operations on the keys (EX: AES
encrypting a block of data using CryptoAPI without being able to read the key.
5) Key-rings should be automatically associated with the following things.
This is also the search order when looking for a key.
Thread
Process
Process Group
Session
User
Group
6) User process with the appropriate privileges (Perhaps a new capability
CAP_LINUX_KEYS or something) can modify/search/link/whatever any/all
keyrings. (I'm still not quite sure how much should be allowed.)
7) All algorithms working with keys and keyrings should be iterative, not
recursive, and should be run it process context.
8) Graphs of nested key-rings must be non-circular.
9) All memory allocated for key-rings and keys should be counted from various limits associated with users/processes/etc.
10) All kernel key-types should begin with a "+" character, and user-space
cannot use an unregistered key-type that begins with a "+" character. (This
means that all keys having a key-type beginning with a "+" character have
been validated by kernel code.
11) A key-ring filesystem should be mounted on /proc/keys: types keys/ <keyID>/ control type description state <keyringID>/ control type description state <keyID> => ../<keyID> [symlink]
12) It should be impossible to look up keys by number unless said key
filesystem is mounted. The "control" entries in the key filesystem can be
open()ed to get the kind of file handle that KETCTL manipulates.
13) A new syscall "keyctl":
KEYCTL_NEW_RING: Creates a new key-ring and returns its fd Returns: int filedesc Params: char *desc int *subkeys long subkey_count
KEYCTL_NEW_KEY: Creates a new key and returns its fd Returns: int filedesc Params: char *type char *desc void *data
KEYCTL_SHLOCK KEYCTL_EXLOCK KEYCTL_UNLOCK: A mandatory lock on the key/key-ring Returns: int error Params: int filedesc int flags
KEYCTL_TYPE: Retrieves the "type" field Returns: long bytes_left Params: char *desc long size
KEYCTL_DESC: Retrieves the "desc" field Returns: long bytes_left Params: char *desc long size
KEYCTL_READ: Retrieves the "data" field Returns: long bytes_left Params: char *data long size
KEYCTL_WRITE: Modifies the "data" field Returns: int error Params: char *data long size
KEYCTL_GET: Retrieves the current key fd Returns: int filedesc Params: int type KEY_THREAD KEY_PROCESS KEY_PGROUP KEY_SESSION KEY_USER KEY_GROUP
KEYCTL_SET: Modifies the current key fd Returns: int error Params: int type <See above KEYCTL_GET_KEY> int filedesc
KEYCTL_ENUM: Enumerates through all keys. NOTE: This must only be called with a KEYCTL_SHLOCK, otherwise it might skip keys or repeat keys. Returns: int error Params: int keyring_fd int *key_fd
KEYCTL_LOOKUP: Look for a key by type, but don't recurse Returns: int filedesc
KEYCTL_SEARCH: Searches for a specific key by type Returns: int filedesc Params: char *type char *desc
KEYCTL_ADD: Adds a key to a key-ring Returns: int error Params: int keyring_fd int key_fd
KEYCTL_REMOVE: Removes a key from a key-ring Returns: int error Params: int keyring_fd int key_fd
KEYCTL_CLEAR: Removes all keys from a key-ring Returns: int error Params: int keyring_fd
KEYCTL_REVOKE: Revokes a specific key file descriptor and any key file descriptors it spawned. This should even apply to keyrings! Returns: int error Params: int filedesc
I think that's just about everything. Let me know if I got something wrong
or have another problem with the above.
Cheers, Kyle Moffett
_______________________________________________ OpenAFS-devel mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-devel
