linux-toradex.git/security/keys, branch v3.0.3

KEYS: Fix error handling in construct_key_and_link()

2011-06-22T01:31:45+00:00

Fix error handling in construct_key_and_link().

If construct_alloc_key() returns an error, it shouldn't pass out through
the normal path as the key_serial() called by the kleave() statement
will oops when it gets an error code in the pointer:

  BUG: unable to handle kernel paging request at ffffffffffffff84
  IP: [] request_key_and_link+0x4d7/0x52f
  ..
  Call Trace:
   [] request_key+0x41/0x75
   [] cifs_get_spnego_key+0x206/0x226 [cifs]
   [] CIFS_SessSetup+0x511/0x1234 [cifs]
   [] cifs_setup_session+0x90/0x1ae [cifs]
   [] cifs_get_smb_ses+0x34b/0x40f [cifs]
   [] cifs_mount+0x13f/0x504 [cifs]
   [] cifs_do_mount+0xc4/0x672 [cifs]
   [] mount_fs+0x69/0x155
   [] vfs_kern_mount+0x63/0xa0
   [] do_kern_mount+0x4d/0xdf
   [] do_mount+0x63c/0x69f
   [] sys_mount+0x88/0xc2
   [] system_call_fastpath+0x16/0x1b

Signed-off-by: David Howells 
Acked-by: Jeff Layton 
Signed-off-by: Linus Torvalds

KEYS/DNS: Fix ____call_usermodehelper() to not lose the session keyring

2011-06-17T16:40:48+00:00

____call_usermodehelper() now erases any credentials set by the
subprocess_inf::init() function.  The problem is that commit
17f60a7da150 ("capabilites: allow the application of capability limits
to usermode helpers") creates and commits new credentials with
prepare_kernel_cred() after the call to the init() function.  This wipes
all keyrings after umh_keys_init() is called.

The best way to deal with this is to put the init() call just prior to
the commit_creds() call, and pass the cred pointer to init().  That
means that umh_keys_init() and suchlike can modify the credentials
_before_ they are published and potentially in use by the rest of the
system.

This prevents request_key() from working as it is prevented from passing
the session keyring it set up with the authorisation token to
/sbin/request-key, and so the latter can't assume the authority to
instantiate the key.  This causes the in-kernel DNS resolver to fail
with ENOKEY unconditionally.

Signed-off-by: David Howells 
Acked-by: Eric Paris 
Tested-by: Jeff Layton 
Signed-off-by: Linus Torvalds

Merge branch 'docs-move' of git://git.kernel.org/pub/scm/linux/kernel/git/rdunlap/linux-docs

2011-05-27T17:25:02+00:00

* 'docs-move' of git://git.kernel.org/pub/scm/linux/kernel/git/rdunlap/linux-docs:
  Create Documentation/security/, move LSM-, credentials-, and keys-related files from Documentation/   to Documentation/security/, add Documentation/security/00-INDEX, and update all occurrences of Documentation/   to Documentation/security/.

Set cred->user_ns in key_replace_session_keyring

2011-05-26T20:49:19+00:00

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

Merge branch 'next' into for-linus

2011-05-24T12:55:24+00:00

Create Documentation/security/,

2011-05-19T22:59:38+00:00

move LSM-, credentials-, and keys-related files from Documentation/
  to Documentation/security/,
add Documentation/security/00-INDEX, and
update all occurrences of Documentation/
  to Documentation/security/.

security,rcu: convert call_rcu(user_update_rcu_disposal) to kfree_rcu()

2011-05-08T05:50:54+00:00

The rcu callback user_update_rcu_disposal() just calls a kfree(),
so we use kfree_rcu() instead of the call_rcu(user_update_rcu_disposal).

Signed-off-by: Lai Jiangshan 
Signed-off-by: Paul E. McKenney 
Acked-by: David Howells 
Reviewed-by: Josh Triplett

KEYS: Make request_key() and co. return an error for a negative key

2011-03-17T00:59:49+00:00

Make request_key() and co. return an error for a negative or rejected key.  If
the key was simply negated, then return ENOKEY, otherwise return the error
with which it was rejected.

Without this patch, the following command returns a key number (with the latest
keyutils):

	[root@andromeda ~]# keyctl request2 user debug:foo rejected @s
	586569904

Trying to print the key merely gets you a permission denied error:

	[root@andromeda ~]# keyctl print 586569904
	keyctl_read_alloc: Permission denied

Doing another request_key() call does get you the error, as long as it hasn't
expired yet:

	[root@andromeda ~]# keyctl request user debug:foo
	request_key: Key was rejected by service

Signed-off-by: David Howells 
Signed-off-by: James Morris

KEYS: Improve /proc/keys

2011-03-17T00:59:32+00:00

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: Add an iovec version of KEYCTL_INSTANTIATE

2011-03-08T00:17:22+00:00

Add a keyctl op (KEYCTL_INSTANTIATE_IOV) that is like KEYCTL_INSTANTIATE, but
takes an iovec array and concatenates the data in-kernel into one buffer.
Since the KEYCTL_INSTANTIATE copies the data anyway, this isn't too much of a
problem.

Signed-off-by: David Howells 
Signed-off-by: James Morris