kernel/git/stable/linux.git/security/keys, branch linux-2.6.31.y

KEYS: get_instantiation_keyring() should inc the keyring refcount in all cases

2009-11-10T00:22:49+00:00

commit 21279cfa107af07ef985539ac0de2152b9cba5f5 upstream. The destination keyring specified to request_key() and co. is made available to the process that instantiates the key (the slave process started by /sbin/request-key typically). This is passed in the request_key_auth struct as the dest_keyring member. keyctl_instantiate_key and keyctl_negate_key() call get_instantiation_keyring() to get the keyring to attach the newly constructed key to at the end of instantiation. This may be given a specific keyring into which a link will be made later, or it may be asked to find the keyring passed to request_key(). In the former case, it returns a keyring with the refcount incremented by lookup_user_key(); in the latter case, it returns the keyring from the request_key_auth struct - and does _not_ increment the refcount. The latter case will eventually result in an oops when the keyring prematurely runs out of references and gets destroyed. The effect may take some time to show up as the key is destroyed lazily. To fix this, the keyring returned by get_instantiation_keyring() must always have its refcount incremented, no matter where it comes from. This can be tested by setting /etc/request-key.conf to: #OP TYPE DESCRIPTION CALLOUT INFO PROGRAM ARG1 ARG2 ARG3 ... #====== ======= =============== =============== =============================== create * test:* * |/bin/false %u %g %d %{user:_display} negate * * * /bin/keyctl negate %k 10 @u and then doing: keyctl add user _display aaaaaaaa @u while keyctl request2 user test:x test:x @u && keyctl list @u; do keyctl request2 user test:x test:x @u; sleep 31; keyctl list @u; done which will oops eventually. Changing the negate line to have @u rather than %S at the end is important as that forces the latter case by passing a special keyring ID rather than an actual keyring ID. Reported-by: Alexander Zangerl Signed-off-by: David Howells Tested-by: Alexander Zangerl Signed-off-by: Linus Torvalds Cc: Chuck Ebbert Signed-off-by: Greg Kroah-Hartman

keys: Handle there being no fallback destination keyring for request_key()

2009-04-09T17:41:19+00:00

When request_key() is called, without there being any standard process keyrings on which to fall back if a destination keyring is not specified, an oops is liable to occur when construct_alloc_key() calls down_write() on dest_keyring's semaphore. Due to function inlining this may be seen as an oops in down_write() as called from request_key_and_link(). This situation crops up during boot, where request_key() is called from within the kernel (such as in CIFS mounts) where nobody is actually logged in, and so PAM has not had a chance to create a session keyring and user keyrings to act as the fallback. To fix this, make construct_alloc_key() not attempt to cache a key if there is no fallback key if no destination keyring is given specifically. Signed-off-by: David Howells Tested-by: Jeff Layton Signed-off-by: Linus Torvalds

keys: make procfiles per-user-namespace

2009-02-27T01:35:15+00:00

Restrict the /proc/keys and /proc/key-users output to keys belonging to the same user namespace as the reading task. We may want to make this more complicated - so that any keys in a user-namespace which is belongs to the reading task are also shown. But let's see if anyone wants that first. Signed-off-by: Serge E. Hallyn Acked-by: David Howells Signed-off-by: James Morris

keys: skip keys from another user namespace

2009-02-27T01:35:12+00:00

When listing keys, do not return keys belonging to the same uid in another user namespace. Otherwise uid 500 in another user namespace will return keyrings called uid.500 for another user namespace. Signed-off-by: Serge E. Hallyn Acked-by: David Howells Signed-off-by: James Morris

keys: consider user namespace in key_permission

2009-02-27T01:35:09+00:00

If a key is owned by another user namespace, then treat the key as though it is owned by both another uid and gid. Signed-off-by: Serge E. Hallyn Acked-by: David Howells Signed-off-by: James Morris

keys: distinguish per-uid keys in different namespaces

2009-02-27T01:35:06+00:00

per-uid keys were looked by uid only. Use the user namespace to distinguish the same uid in different namespaces. This does not address key_permission. So a task can for instance try to join a keyring owned by the same uid in another namespace. That will be handled by a separate patch. Signed-off-by: Serge E. Hallyn Acked-by: David Howells Signed-off-by: James Morris

security: introduce missing kfree

2009-01-17T22:24:46+00:00

Plug this leak. Acked-by: David Howells Cc: James Morris Cc: Signed-off-by: Vegard Nossum Signed-off-by: Linus Torvalds

[CVE-2009-0029] System call wrappers part 28

2009-01-14T13:15:30+00:00

Signed-off-by: Heiko Carstens

[CVE-2009-0029] System call wrappers part 27

2009-01-14T13:15:29+00:00

Signed-off-by: Heiko Carstens

keys: fix sparse warning by adding __user annotation to cast

2008-12-31T23:32:44+00:00

Fix the following sparse warning: CC security/keys/key.o security/keys/keyctl.c:1297:10: warning: incorrect type in argument 2 (different address spaces) security/keys/keyctl.c:1297:10: expected char [noderef] *buffer security/keys/keyctl.c:1297:10: got char * which appears to be caused by lack of __user annotation to the cast of a syscall argument. Signed-off-by: James Morris Acked-by: David Howells