linux/security/keys/process_keys.c, branch v3.4.3

KEYS: testing wrong bit for KEY_FLAG_REVOKED

2012-03-07T00:12:06Z

The test for "if (cred->request_key_auth->flags & KEY_FLAG_REVOKED) {" should actually testing that the (1 << KEY_FLAG_REVOKED) bit is set. The current code actually checks for KEY_FLAG_DEAD. Signed-off-by: Dan Carpenter Signed-off-by: David Howells Signed-off-by: James Morris

KEYS: keyctl_get_keyring_ID() should create a session keyring if create flag set

2011-08-22T23:57:34Z

The keyctl call: keyctl_get_keyring_ID(KEY_SPEC_SESSION_KEYRING, 1) should create a session keyring if the process doesn't have one of its own because the create flag argument is set - rather than subscribing to and returning the user-session keyring as: keyctl_get_keyring_ID(KEY_SPEC_SESSION_KEYRING, 0) will do. This can be tested by commenting out pam_keyinit in the /etc/pam.d files and running the following program a couple of times in a row: #include #include #include int main(int argc, char *argv[]) { key_serial_t uk, usk, sk, nsk; uk = keyctl_get_keyring_ID(KEY_SPEC_USER_KEYRING, 0); usk = keyctl_get_keyring_ID(KEY_SPEC_USER_SESSION_KEYRING, 0); sk = keyctl_get_keyring_ID(KEY_SPEC_SESSION_KEYRING, 0); nsk = keyctl_get_keyring_ID(KEY_SPEC_SESSION_KEYRING, 1); printf("keys: %08x %08x %08x %08x\n", uk, usk, sk, nsk); return 0; } Without this patch, I see: keys: 3975ddc7 119c0c66 119c0c66 119c0c66 keys: 3975ddc7 119c0c66 119c0c66 119c0c66 With this patch, I see: keys: 2cb4997b 34112878 34112878 17db2ce3 keys: 2cb4997b 34112878 34112878 39f3c73e As can be seen, the session keyring starts off the same as the user-session keyring each time, but with the patch a new session keyring is created when the create flag is set. Reported-by: Greg Wettstein Signed-off-by: David Howells Tested-by: Greg Wettstein Signed-off-by: James Morris

KEYS: If install_session_keyring() is given a keyring, it should install it

2011-08-22T23:57:33Z

If install_session_keyring() is given a keyring, it should install it rather than just creating a new one anyway. This was accidentally broken in: commit d84f4f992cbd76e8f39c488cf0c5d123843923b1 Author: David Howells Date: Fri Nov 14 10:39:23 2008 +1100 Subject: CRED: Inaugurate COW credentials The impact of that commit is that pam_keyinit no longer works correctly if 'force' isn't specified against a login process. This is because: keyctl_get_keyring_ID(KEY_SPEC_SESSION_KEYRING, 0) now always creates a new session keyring and thus the check whether the session keyring and the user-session keyring are the same is always false. This leads pam_keyinit to conclude that a session keyring is installed and it shouldn't be revoked by pam_keyinit here if 'revoke' is specified. Any system that specifies 'force' against pam_keyinit in the PAM configuration files for login methods (login, ssh, su -l, kdm, etc.) is not affected since that bypasses the broken check and forces the creation of a new session keyring anyway (for which the revoke flag is not cleared) - and any subsequent call to pam_keyinit really does have a session keyring already installed, and so the check works correctly there. Reverting to the previous behaviour will cause the kernel to subscribe the process to the user-session keyring as its session keyring if it doesn't have a session keyring of its own. pam_keyinit will detect this and install a new session keyring anyway (and won't clear the revert flag). This can be tested by commenting out pam_keyinit in the /etc/pam.d files and running the following program a couple of times in a row: #include #include #include int main(int argc, char *argv[]) { key_serial_t uk, usk, sk; uk = keyctl_get_keyring_ID(KEY_SPEC_USER_KEYRING, 0); usk = keyctl_get_keyring_ID(KEY_SPEC_USER_SESSION_KEYRING, 0); sk = keyctl_get_keyring_ID(KEY_SPEC_SESSION_KEYRING, 0); printf("keys: %08x %08x %08x\n", uk, usk, sk); return 0; } Without the patch, I see: keys: 3884e281 24c4dfcf 22825f8e keys: 3884e281 24c4dfcf 068772be With the patch, I see: keys: 26be9c83 0e755ce0 0e755ce0 keys: 26be9c83 0e755ce0 0e755ce0 As can be seen, with the patch, the session keyring is the same as the user-session keyring each time; without the patch a new session keyring is generated each time. Reported-by: Greg Wettstein Signed-off-by: David Howells Tested-by: Greg Wettstein Signed-off-by: James Morris

Set cred->user_ns in key_replace_session_keyring

2011-05-26T20:49:19Z

Since this cred was not created with copy_creds(), it needs to get initialized. Otherwise use of syscall(__NR_keyctl, KEYCTL_SESSION_TO_PARENT); can lead to a NULL deref. Thanks to Robert for finding this. But introduced by commit 47a150edc2a ("Cache user_ns in struct cred"). Signed-off-by: Serge E. Hallyn Reported-by: Robert Święcki Cc: David Howells Cc: stable@kernel.org (2.6.39) Signed-off-by: Linus Torvalds

KEYS: Improve /proc/keys

2011-03-17T00:59:32Z

Improve /proc/keys by: (1) Don't attempt to summarise the payload of a negated key. It won't have one. To this end, a helper function - key_is_instantiated() has been added that allows the caller to find out whether the key is positively instantiated (as opposed to being uninstantiated or negatively instantiated). (2) Do show keys that are negative, expired or revoked rather than hiding them. This requires an override flag (no_state_check) to be passed to search_my_process_keyrings() and keyring_search_aux() to suppress this check. Without this, keys that are possessed by the caller, but only grant permissions to the caller if possessed are skipped as the possession check fails. Keys that are visible due to user, group or other checks are visible with or without this patch. Signed-off-by: David Howells Signed-off-by: James Morris

KEYS: Fix up comments in key management code

2011-01-21T22:59:30Z

Fix up comments in the key management code. No functional changes. Signed-off-by: David Howells Signed-off-by: Linus Torvalds

KEYS: Do some style cleanup in the key management code.

2011-01-21T22:59:29Z

Do a bit of a style clean up in the key management code. No functional changes. Done using: perl -p -i -e 's!^/[*]*/\n!!' security/keys/*.c perl -p -i -e 's!} /[*] end [a-z0-9_]*[(][)] [*]/\n!}\n!' security/keys/*.c sed -i -s -e ": next" -e N -e 's/^\n[}]$/}/' -e t -e P -e 's/^.*\n//' -e "b next" security/keys/*.c To remove /*****/ lines, remove comments on the closing brace of a function to name the function and remove blank lines before the closing brace of a function. Signed-off-by: David Howells Signed-off-by: Linus Torvalds

Fix install_process_keyring error handling

2010-10-28T16:02:15Z

Fix an incorrect error check that returns 1 for error instead of the expected error code. Signed-off-by: Andi Kleen Signed-off-by: David Howells Signed-off-by: Linus Torvalds

KEYS: Make /proc/keys check to see if a key is possessed before security check

2010-08-02T05:34:27Z

Make /proc/keys check to see if the calling process possesses each key before performing the security check. The possession check can be skipped if the key doesn't have the possessor-view permission bit set. This causes the keys a process possesses to show up in /proc/keys, even if they don't have matching user/group/other view permissions. Signed-off-by: David Howells Signed-off-by: James Morris

umh: creds: convert call_usermodehelper_keys() to use subprocess_info->init()

2010-05-27T16:12:45Z

call_usermodehelper_keys() uses call_usermodehelper_setkeys() to change subprocess_info->cred in advance. Now that we have info->init() we can change this code to set tgcred->session_keyring in context of execing kernel thread. Note: since currently call_usermodehelper_keys() is never called with UMH_NO_WAIT, call_usermodehelper_keys()->key_get() and umh_keys_cleanup() are not really needed, we could rely on install_session_keyring_to_cred() which does key_get() on success. Signed-off-by: Oleg Nesterov Acked-by: Neil Horman Acked-by: David Howells Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds