1. 05 5月, 2010 1 次提交
    • T
      KEYS: find_keyring_by_name() can gain access to a freed keyring · cea7daa3
      Toshiyuki Okajima 提交于
      find_keyring_by_name() can gain access to a keyring that has had its reference
      count reduced to zero, and is thus ready to be freed.  This then allows the
      dead keyring to be brought back into use whilst it is being destroyed.
      
      The following timeline illustrates the process:
      
      |(cleaner)                           (user)
      |
      | free_user(user)                    sys_keyctl()
      |  |                                  |
      |  key_put(user->session_keyring)     keyctl_get_keyring_ID()
      |  ||	//=> keyring->usage = 0        |
      |  |schedule_work(&key_cleanup_task)   lookup_user_key()
      |  ||                                   |
      |  kmem_cache_free(,user)               |
      |  .                                    |[KEY_SPEC_USER_KEYRING]
      |  .                                    install_user_keyrings()
      |  .                                    ||
      | key_cleanup() [<= worker_thread()]    ||
      |  |                                    ||
      |  [spin_lock(&key_serial_lock)]        |[mutex_lock(&key_user_keyr..mutex)]
      |  |                                    ||
      |  atomic_read() == 0                   ||
      |  |{ rb_ease(&key->serial_node,) }     ||
      |  |                                    ||
      |  [spin_unlock(&key_serial_lock)]      |find_keyring_by_name()
      |  |                                    |||
      |  keyring_destroy(keyring)             ||[read_lock(&keyring_name_lock)]
      |  ||                                   |||
      |  |[write_lock(&keyring_name_lock)]    ||atomic_inc(&keyring->usage)
      |  |.                                   ||| *** GET freeing keyring ***
      |  |.                                   ||[read_unlock(&keyring_name_lock)]
      |  ||                                   ||
      |  |list_del()                          |[mutex_unlock(&key_user_k..mutex)]
      |  ||                                   |
      |  |[write_unlock(&keyring_name_lock)]  ** INVALID keyring is returned **
      |  |                                    .
      |  kmem_cache_free(,keyring)            .
      |                                       .
      |                                       atomic_dec(&keyring->usage)
      v                                         *** DESTROYED ***
      TIME
      
      If CONFIG_SLUB_DEBUG=y then we may see the following message generated:
      
      	=============================================================================
      	BUG key_jar: Poison overwritten
      	-----------------------------------------------------------------------------
      
      	INFO: 0xffff880197a7e200-0xffff880197a7e200. First byte 0x6a instead of 0x6b
      	INFO: Allocated in key_alloc+0x10b/0x35f age=25 cpu=1 pid=5086
      	INFO: Freed in key_cleanup+0xd0/0xd5 age=12 cpu=1 pid=10
      	INFO: Slab 0xffffea000592cb90 objects=16 used=2 fp=0xffff880197a7e200 flags=0x200000000000c3
      	INFO: Object 0xffff880197a7e200 @offset=512 fp=0xffff880197a7e300
      
      	Bytes b4 0xffff880197a7e1f0:  5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZZZZZ
      	  Object 0xffff880197a7e200:  6a 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b jkkkkkkkkkkkkkkk
      
      Alternatively, we may see a system panic happen, such as:
      
      	BUG: unable to handle kernel NULL pointer dereference at 0000000000000001
      	IP: [<ffffffff810e61a3>] kmem_cache_alloc+0x5b/0xe9
      	PGD 6b2b4067 PUD 6a80d067 PMD 0
      	Oops: 0000 [#1] SMP
      	last sysfs file: /sys/kernel/kexec_crash_loaded
      	CPU 1
      	...
      	Pid: 31245, comm: su Not tainted 2.6.34-rc5-nofixed-nodebug #2 D2089/PRIMERGY
      	RIP: 0010:[<ffffffff810e61a3>]  [<ffffffff810e61a3>] kmem_cache_alloc+0x5b/0xe9
      	RSP: 0018:ffff88006af3bd98  EFLAGS: 00010002
      	RAX: 0000000000000000 RBX: 0000000000000001 RCX: ffff88007d19900b
      	RDX: 0000000100000000 RSI: 00000000000080d0 RDI: ffffffff81828430
      	RBP: ffffffff81828430 R08: ffff88000a293750 R09: 0000000000000000
      	R10: 0000000000000001 R11: 0000000000100000 R12: 00000000000080d0
      	R13: 00000000000080d0 R14: 0000000000000296 R15: ffffffff810f20ce
      	FS:  00007f97116bc700(0000) GS:ffff88000a280000(0000) knlGS:0000000000000000
      	CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      	CR2: 0000000000000001 CR3: 000000006a91c000 CR4: 00000000000006e0
      	DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      	DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      	Process su (pid: 31245, threadinfo ffff88006af3a000, task ffff8800374414c0)
      	Stack:
      	 0000000512e0958e 0000000000008000 ffff880037f8d180 0000000000000001
      	 0000000000000000 0000000000008001 ffff88007d199000 ffffffff810f20ce
      	 0000000000008000 ffff88006af3be48 0000000000000024 ffffffff810face3
      	Call Trace:
      	 [<ffffffff810f20ce>] ? get_empty_filp+0x70/0x12f
      	 [<ffffffff810face3>] ? do_filp_open+0x145/0x590
      	 [<ffffffff810ce208>] ? tlb_finish_mmu+0x2a/0x33
      	 [<ffffffff810ce43c>] ? unmap_region+0xd3/0xe2
      	 [<ffffffff810e4393>] ? virt_to_head_page+0x9/0x2d
      	 [<ffffffff81103916>] ? alloc_fd+0x69/0x10e
      	 [<ffffffff810ef4ed>] ? do_sys_open+0x56/0xfc
      	 [<ffffffff81008a02>] ? system_call_fastpath+0x16/0x1b
      	Code: 0f 1f 44 00 00 49 89 c6 fa 66 0f 1f 44 00 00 65 4c 8b 04 25 60 e8 00 00 48 8b 45 00 49 01 c0 49 8b 18 48 85 db 74 0d 48 63 45 18 <48> 8b 04 03 49 89 00 eb 14 4c 89 f9 83 ca ff 44 89 e6 48 89 ef
      	RIP  [<ffffffff810e61a3>] kmem_cache_alloc+0x5b/0xe9
      
      This problem is that find_keyring_by_name does not confirm that the keyring is
      valid before accepting it.
      
      Skipping keyrings that have been reduced to a zero count seems the way to go.
      To this end, use atomic_inc_not_zero() to increment the usage count and skip
      the candidate keyring if that returns false.
      
      The following script _may_ cause the bug to happen, but there's no guarantee
      as the window of opportunity is small:
      
      	#!/bin/sh
      	LOOP=100000
      	USER=dummy_user
      	/bin/su -c "exit;" $USER || { /usr/sbin/adduser -m $USER; add=1; }
      	for ((i=0; i<LOOP; i++))
      	do
      		/bin/su -c "echo '$i' > /dev/null" $USER
      	done
      	(( add == 1 )) && /usr/sbin/userdel -r $USER
      	exit
      
      Note that the nominated user must not be in use.
      
      An alternative way of testing this may be:
      
      	for ((i=0; i<100000; i++))
      	do
      		keyctl session foo /bin/true || break
      	done >&/dev/null
      
      as that uses a keyring named "foo" rather than relying on the user and
      user-session named keyrings.
      Reported-by: NToshiyuki Okajima <toshi.okajima@jp.fujitsu.com>
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Tested-by: NToshiyuki Okajima <toshi.okajima@jp.fujitsu.com>
      Acked-by: NSerge Hallyn <serue@us.ibm.com>
      Signed-off-by: NJames Morris <jmorris@namei.org>
      cea7daa3
  2. 28 4月, 2010 1 次提交
    • D
      keys: don't need to use RCU in keyring_read() as semaphore is held · b59ec78c
      David Howells 提交于
      keyring_read() doesn't need to use rcu_dereference() to access the keyring
      payload as the caller holds the key semaphore to prevent modifications
      from happening whilst the data is read out.
      
      This should solve the following warning:
      
      ===================================================
      [ INFO: suspicious rcu_dereference_check() usage. ]
      ---------------------------------------------------
      security/keys/keyring.c:204 invoked rcu_dereference_check() without protection!
      
      other info that might help us debug this:
      
      rcu_scheduler_active = 1, debug_locks = 0
      1 lock held by keyctl/2144:
       #0:  (&key->sem){+++++.}, at: [<ffffffff81177f7c>] keyctl_read_key+0x9c/0xcf
      
      stack backtrace:
      Pid: 2144, comm: keyctl Not tainted 2.6.34-rc2-cachefs #113
      Call Trace:
       [<ffffffff8105121f>] lockdep_rcu_dereference+0xaa/0xb2
       [<ffffffff811762d5>] keyring_read+0x4d/0xe7
       [<ffffffff81177f8c>] keyctl_read_key+0xac/0xcf
       [<ffffffff811788d4>] sys_keyctl+0x75/0xb9
       [<ffffffff81001eeb>] system_call_fastpath+0x16/0x1b
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Cc: Herbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NJames Morris <jmorris@namei.org>
      b59ec78c
  3. 25 2月, 2010 1 次提交
  4. 15 9月, 2009 1 次提交
    • D
      KEYS: Fix garbage collector · c08ef808
      David Howells 提交于
      Fix a number of problems with the new key garbage collector:
      
       (1) A rogue semicolon in keyring_gc() was causing the initial count of dead
           keys to be miscalculated.
      
       (2) A missing return in keyring_gc() meant that under certain circumstances,
           the keyring semaphore would be unlocked twice.
      
       (3) The key serial tree iterator (key_garbage_collector()) part of the garbage
           collector has been modified to:
      
           (a) Complete each scan of the keyrings before setting the new timer.
      
           (b) Only set the new timer for keys that have yet to expire.  This means
               that the new timer is now calculated correctly, and the gc doesn't
               get into a loop continually scanning for keys that have expired, and
               preventing other things from happening, like RCU cleaning up the old
               keyring contents.
      
           (c) Perform an extra scan if any keys were garbage collected in this one
           	 as a key might become garbage during a scan, and (b) could mean we
           	 don't set the timer again.
      
       (4) Made key_schedule_gc() take the time at which to do a collection run,
           rather than the time at which the key expires.  This means the collection
           of dead keys (key type unregistered) can happen immediately.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Signed-off-by: NJames Morris <jmorris@namei.org>
      c08ef808
  5. 02 9月, 2009 1 次提交
    • D
      KEYS: Add garbage collection for dead, revoked and expired keys. [try #6] · 5d135440
      David Howells 提交于
      Add garbage collection for dead, revoked and expired keys.  This involved
      erasing all links to such keys from keyrings that point to them.  At that
      point, the key will be deleted in the normal manner.
      
      Keyrings from which garbage collection occurs are shrunk and their quota
      consumption reduced as appropriate.
      
      Dead keys (for which the key type has been removed) will be garbage collected
      immediately.
      
      Revoked and expired keys will hang around for a number of seconds, as set in
      /proc/sys/kernel/keys/gc_delay before being automatically removed.  The default
      is 5 minutes.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Signed-off-by: NJames Morris <jmorris@namei.org>
      5d135440
  6. 27 2月, 2009 1 次提交
  7. 14 11月, 2008 2 次提交
    • D
      CRED: Inaugurate COW credentials · d84f4f99
      David Howells 提交于
      Inaugurate copy-on-write credentials management.  This uses RCU to manage the
      credentials pointer in the task_struct with respect to accesses by other tasks.
      A process may only modify its own credentials, and so does not need locking to
      access or modify its own credentials.
      
      A mutex (cred_replace_mutex) is added to the task_struct to control the effect
      of PTRACE_ATTACHED on credential calculations, particularly with respect to
      execve().
      
      With this patch, the contents of an active credentials struct may not be
      changed directly; rather a new set of credentials must be prepared, modified
      and committed using something like the following sequence of events:
      
      	struct cred *new = prepare_creds();
      	int ret = blah(new);
      	if (ret < 0) {
      		abort_creds(new);
      		return ret;
      	}
      	return commit_creds(new);
      
      There are some exceptions to this rule: the keyrings pointed to by the active
      credentials may be instantiated - keyrings violate the COW rule as managing
      COW keyrings is tricky, given that it is possible for a task to directly alter
      the keys in a keyring in use by another task.
      
      To help enforce this, various pointers to sets of credentials, such as those in
      the task_struct, are declared const.  The purpose of this is compile-time
      discouragement of altering credentials through those pointers.  Once a set of
      credentials has been made public through one of these pointers, it may not be
      modified, except under special circumstances:
      
        (1) Its reference count may incremented and decremented.
      
        (2) The keyrings to which it points may be modified, but not replaced.
      
      The only safe way to modify anything else is to create a replacement and commit
      using the functions described in Documentation/credentials.txt (which will be
      added by a later patch).
      
      This patch and the preceding patches have been tested with the LTP SELinux
      testsuite.
      
      This patch makes several logical sets of alteration:
      
       (1) execve().
      
           This now prepares and commits credentials in various places in the
           security code rather than altering the current creds directly.
      
       (2) Temporary credential overrides.
      
           do_coredump() and sys_faccessat() now prepare their own credentials and
           temporarily override the ones currently on the acting thread, whilst
           preventing interference from other threads by holding cred_replace_mutex
           on the thread being dumped.
      
           This will be replaced in a future patch by something that hands down the
           credentials directly to the functions being called, rather than altering
           the task's objective credentials.
      
       (3) LSM interface.
      
           A number of functions have been changed, added or removed:
      
           (*) security_capset_check(), ->capset_check()
           (*) security_capset_set(), ->capset_set()
      
           	 Removed in favour of security_capset().
      
           (*) security_capset(), ->capset()
      
           	 New.  This is passed a pointer to the new creds, a pointer to the old
           	 creds and the proposed capability sets.  It should fill in the new
           	 creds or return an error.  All pointers, barring the pointer to the
           	 new creds, are now const.
      
           (*) security_bprm_apply_creds(), ->bprm_apply_creds()
      
           	 Changed; now returns a value, which will cause the process to be
           	 killed if it's an error.
      
           (*) security_task_alloc(), ->task_alloc_security()
      
           	 Removed in favour of security_prepare_creds().
      
           (*) security_cred_free(), ->cred_free()
      
           	 New.  Free security data attached to cred->security.
      
           (*) security_prepare_creds(), ->cred_prepare()
      
           	 New. Duplicate any security data attached to cred->security.
      
           (*) security_commit_creds(), ->cred_commit()
      
           	 New. Apply any security effects for the upcoming installation of new
           	 security by commit_creds().
      
           (*) security_task_post_setuid(), ->task_post_setuid()
      
           	 Removed in favour of security_task_fix_setuid().
      
           (*) security_task_fix_setuid(), ->task_fix_setuid()
      
           	 Fix up the proposed new credentials for setuid().  This is used by
           	 cap_set_fix_setuid() to implicitly adjust capabilities in line with
           	 setuid() changes.  Changes are made to the new credentials, rather
           	 than the task itself as in security_task_post_setuid().
      
           (*) security_task_reparent_to_init(), ->task_reparent_to_init()
      
           	 Removed.  Instead the task being reparented to init is referred
           	 directly to init's credentials.
      
      	 NOTE!  This results in the loss of some state: SELinux's osid no
      	 longer records the sid of the thread that forked it.
      
           (*) security_key_alloc(), ->key_alloc()
           (*) security_key_permission(), ->key_permission()
      
           	 Changed.  These now take cred pointers rather than task pointers to
           	 refer to the security context.
      
       (4) sys_capset().
      
           This has been simplified and uses less locking.  The LSM functions it
           calls have been merged.
      
       (5) reparent_to_kthreadd().
      
           This gives the current thread the same credentials as init by simply using
           commit_thread() to point that way.
      
       (6) __sigqueue_alloc() and switch_uid()
      
           __sigqueue_alloc() can't stop the target task from changing its creds
           beneath it, so this function gets a reference to the currently applicable
           user_struct which it then passes into the sigqueue struct it returns if
           successful.
      
           switch_uid() is now called from commit_creds(), and possibly should be
           folded into that.  commit_creds() should take care of protecting
           __sigqueue_alloc().
      
       (7) [sg]et[ug]id() and co and [sg]et_current_groups.
      
           The set functions now all use prepare_creds(), commit_creds() and
           abort_creds() to build and check a new set of credentials before applying
           it.
      
           security_task_set[ug]id() is called inside the prepared section.  This
           guarantees that nothing else will affect the creds until we've finished.
      
           The calling of set_dumpable() has been moved into commit_creds().
      
           Much of the functionality of set_user() has been moved into
           commit_creds().
      
           The get functions all simply access the data directly.
      
       (8) security_task_prctl() and cap_task_prctl().
      
           security_task_prctl() has been modified to return -ENOSYS if it doesn't
           want to handle a function, or otherwise return the return value directly
           rather than through an argument.
      
           Additionally, cap_task_prctl() now prepares a new set of credentials, even
           if it doesn't end up using it.
      
       (9) Keyrings.
      
           A number of changes have been made to the keyrings code:
      
           (a) switch_uid_keyring(), copy_keys(), exit_keys() and suid_keys() have
           	 all been dropped and built in to the credentials functions directly.
           	 They may want separating out again later.
      
           (b) key_alloc() and search_process_keyrings() now take a cred pointer
           	 rather than a task pointer to specify the security context.
      
           (c) copy_creds() gives a new thread within the same thread group a new
           	 thread keyring if its parent had one, otherwise it discards the thread
           	 keyring.
      
           (d) The authorisation key now points directly to the credentials to extend
           	 the search into rather pointing to the task that carries them.
      
           (e) Installing thread, process or session keyrings causes a new set of
           	 credentials to be created, even though it's not strictly necessary for
           	 process or session keyrings (they're shared).
      
      (10) Usermode helper.
      
           The usermode helper code now carries a cred struct pointer in its
           subprocess_info struct instead of a new session keyring pointer.  This set
           of credentials is derived from init_cred and installed on the new process
           after it has been cloned.
      
           call_usermodehelper_setup() allocates the new credentials and
           call_usermodehelper_freeinfo() discards them if they haven't been used.  A
           special cred function (prepare_usermodeinfo_creds()) is provided
           specifically for call_usermodehelper_setup() to call.
      
           call_usermodehelper_setkeys() adjusts the credentials to sport the
           supplied keyring as the new session keyring.
      
      (11) SELinux.
      
           SELinux has a number of changes, in addition to those to support the LSM
           interface changes mentioned above:
      
           (a) selinux_setprocattr() no longer does its check for whether the
           	 current ptracer can access processes with the new SID inside the lock
           	 that covers getting the ptracer's SID.  Whilst this lock ensures that
           	 the check is done with the ptracer pinned, the result is only valid
           	 until the lock is released, so there's no point doing it inside the
           	 lock.
      
      (12) is_single_threaded().
      
           This function has been extracted from selinux_setprocattr() and put into
           a file of its own in the lib/ directory as join_session_keyring() now
           wants to use it too.
      
           The code in SELinux just checked to see whether a task shared mm_structs
           with other tasks (CLONE_VM), but that isn't good enough.  We really want
           to know if they're part of the same thread group (CLONE_THREAD).
      
      (13) nfsd.
      
           The NFS server daemon now has to use the COW credentials to set the
           credentials it is going to use.  It really needs to pass the credentials
           down to the functions it calls, but it can't do that until other patches
           in this series have been applied.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Acked-by: NJames Morris <jmorris@namei.org>
      Signed-off-by: NJames Morris <jmorris@namei.org>
      d84f4f99
    • D
      KEYS: Disperse linux/key_ui.h · e9e349b0
      David Howells 提交于
      Disperse the bits of linux/key_ui.h as the reason they were put here (keyfs)
      didn't get in.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Reviewed-by: NJames Morris <jmorris@namei.org>
      Signed-off-by: NJames Morris <jmorris@namei.org>
      e9e349b0
  8. 29 4月, 2008 2 次提交
    • D
      keys: don't generate user and user session keyrings unless they're accessed · 69664cf1
      David Howells 提交于
      Don't generate the per-UID user and user session keyrings unless they're
      explicitly accessed.  This solves a problem during a login process whereby
      set*uid() is called before the SELinux PAM module, resulting in the per-UID
      keyrings having the wrong security labels.
      
      This also cures the problem of multiple per-UID keyrings sometimes appearing
      due to PAM modules (including pam_keyinit) setuiding and causing user_structs
      to come into and go out of existence whilst the session keyring pins the user
      keyring.  This is achieved by first searching for extant per-UID keyrings
      before inventing new ones.
      
      The serial bound argument is also dropped from find_keyring_by_name() as it's
      not currently made use of (setting it to 0 disables the feature).
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Cc: <kwc@citi.umich.edu>
      Cc: <arunsr@cse.iitk.ac.in>
      Cc: <dwalsh@redhat.com>
      Cc: Stephen Smalley <sds@tycho.nsa.gov>
      Cc: James Morris <jmorris@namei.org>
      Cc: Chris Wright <chrisw@sous-sol.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      69664cf1
    • K
      keys: check starting keyring as part of search · dceba994
      Kevin Coffman 提交于
      Check the starting keyring as part of the search to (a) see if that is what
      we're searching for, and (b) to check it is still valid for searching.
      
      The scenario: User in process A does things that cause things to be created in
      its process session keyring.  The user then does an su to another user and
      starts a new process, B.  The two processes now share the same process session
      keyring.
      
      Process B does an NFS access which results in an upcall to gssd.  When gssd
      attempts to instantiate the context key (to be linked into the process session
      keyring), it is denied access even though it has an authorization key.
      
      The order of calls is:
      
         keyctl_instantiate_key()
            lookup_user_key()				    (the default: case)
               search_process_keyrings(current)
      	    search_process_keyrings(rka->context)   (recursive call)
      	       keyring_search_aux()
      
      keyring_search_aux() verifies the keys and keyrings underneath the top-level
      keyring it is given, but that top-level keyring is neither fully validated nor
      checked to see if it is the thing being searched for.
      
      This patch changes keyring_search_aux() to:
      1) do more validation on the top keyring it is given and
      2) check whether that top-level keyring is the thing being searched for
      Signed-off-by: NKevin Coffman <kwc@citi.umich.edu>
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Cc: Paul Moore <paul.moore@hp.com>
      Cc: Chris Wright <chrisw@sous-sol.org>
      Cc: Stephen Smalley <sds@tycho.nsa.gov>
      Cc: James Morris <jmorris@namei.org>
      Cc: Kevin Coffman <kwc@citi.umich.edu>
      Cc: Trond Myklebust <trond.myklebust@fys.uio.no>
      Cc: "J. Bruce Fields" <bfields@fieldses.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      dceba994
  9. 27 4月, 2007 1 次提交
  10. 08 12月, 2006 1 次提交
  11. 27 6月, 2006 2 次提交
  12. 23 6月, 2006 1 次提交
  13. 11 4月, 2006 1 次提交
    • D
      [Security] Keys: Fix oops when adding key to non-keyring · c3a9d654
      David Howells 提交于
      This fixes the problem of an oops occuring when a user attempts to add a
      key to a non-keyring key [CVE-2006-1522].
      
      The problem is that __keyring_search_one() doesn't check that the
      keyring it's been given is actually a keyring.
      
      I've fixed this problem by:
      
       (1) declaring that caller of __keyring_search_one() must guarantee that
           the keyring is a keyring; and
      
       (2) making key_create_or_update() check that the keyring is a keyring,
           and return -ENOTDIR if it isn't.
      
      This can be tested by:
      
      	keyctl add user b b `keyctl add user a a @s`
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      c3a9d654
  14. 09 1月, 2006 2 次提交
    • D
      [PATCH] keys: Permit running process to instantiate keys · b5f545c8
      David Howells 提交于
      Make it possible for a running process (such as gssapid) to be able to
      instantiate a key, as was requested by Trond Myklebust for NFS4.
      
      The patch makes the following changes:
      
       (1) A new, optional key type method has been added. This permits a key type
           to intercept requests at the point /sbin/request-key is about to be
           spawned and do something else with them - passing them over the
           rpc_pipefs files or netlink sockets for instance.
      
           The uninstantiated key, the authorisation key and the intended operation
           name are passed to the method.
      
       (2) The callout_info is no longer passed as an argument to /sbin/request-key
           to prevent unauthorised viewing of this data using ps or by looking in
           /proc/pid/cmdline.
      
           This means that the old /sbin/request-key program will not work with the
           patched kernel as it will expect to see an extra argument that is no
           longer there.
      
           A revised keyutils package will be made available tomorrow.
      
       (3) The callout_info is now attached to the authorisation key. Reading this
           key will retrieve the information.
      
       (4) A new field has been added to the task_struct. This holds the
           authorisation key currently active for a thread. Searches now look here
           for the caller's set of keys rather than looking for an auth key in the
           lowest level of the session keyring.
      
           This permits a thread to be servicing multiple requests at once and to
           switch between them. Note that this is per-thread, not per-process, and
           so is usable in multithreaded programs.
      
           The setting of this field is inherited across fork and exec.
      
       (5) A new keyctl function (KEYCTL_ASSUME_AUTHORITY) has been added that
           permits a thread to assume the authority to deal with an uninstantiated
           key. Assumption is only permitted if the authorisation key associated
           with the uninstantiated key is somewhere in the thread's keyrings.
      
           This function can also clear the assumption.
      
       (6) A new magic key specifier has been added to refer to the currently
           assumed authorisation key (KEY_SPEC_REQKEY_AUTH_KEY).
      
       (7) Instantiation will only proceed if the appropriate authorisation key is
           assumed first. The assumed authorisation key is discarded if
           instantiation is successful.
      
       (8) key_validate() is moved from the file of request_key functions to the
           file of permissions functions.
      
       (9) The documentation is updated.
      
      From: <Valdis.Kletnieks@vt.edu>
      
          Build fix.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Cc: Trond Myklebust <trond.myklebust@fys.uio.no>
      Cc: Alexander Zangerl <az@bond.edu.au>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      b5f545c8
    • D
      [PATCH] keys: Discard duplicate keys from a keyring on link · cab8eb59
      David Howells 提交于
      Cause any links within a keyring to keys that match a key to be linked into
      that keyring to be discarded as a link to the new key is added.  The match is
      contingent on the type and description strings being the same.
      
      This permits requests, adds and searches to displace negative, expired,
      revoked and dead keys easily.  After some discussion it was concluded that
      duplicate valid keys should probably be discarded also as they would otherwise
      hide the new key.
      
      Since request_key() is intended to be the primary method by which keys are
      added to a keyring, duplicate valid keys wouldn't be an issue there as that
      function would return an existing match in preference to creating a new key.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Cc: Trond Myklebust <trond.myklebust@fys.uio.no>
      Cc: Alexander Zangerl <az@bond.edu.au>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      cab8eb59
  15. 07 1月, 2006 2 次提交
  16. 02 12月, 2005 1 次提交
  17. 07 11月, 2005 1 次提交
  18. 31 10月, 2005 1 次提交
    • D
      [PATCH] Keys: Add LSM hooks for key management [try #3] · 29db9190
      David Howells 提交于
      The attached patch adds LSM hooks for key management facilities. The notable
      changes are:
      
       (1) The key struct now supports a security pointer for the use of security
           modules. This will permit key labelling and restrictions on which
           programs may access a key.
      
       (2) Security modules get a chance to note (or abort) the allocation of a key.
      
       (3) The key permission checking can now be enhanced by the security modules;
           the permissions check consults LSM if all other checks bear out.
      
       (4) The key permissions checking functions now return an error code rather
           than a boolean value.
      
       (5) An extra permission has been added to govern the modification of
           attributes (UID, GID, permissions).
      
      Note that there isn't an LSM hook specifically for each keyctl() operation,
      but rather the permissions hook allows control of individual operations based
      on the permission request bits.
      
      Key management access control through LSM is enabled by automatically if both
      CONFIG_KEYS and CONFIG_SECURITY are enabled.
      
      This should be applied on top of the patch ensubjected:
      
      	[PATCH] Keys: Possessor permissions should be additive
      Signed-Off-By: NDavid Howells <dhowells@redhat.com>
      Signed-off-by: NChris Wright <chrisw@osdl.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      29db9190
  19. 29 9月, 2005 1 次提交
    • D
      [PATCH] Keys: Add possessor permissions to keys [try #3] · 664cceb0
      David Howells 提交于
      The attached patch adds extra permission grants to keys for the possessor of a
      key in addition to the owner, group and other permissions bits. This makes
      SUID binaries easier to support without going as far as labelling keys and key
      targets using the LSM facilities.
      
      This patch adds a second "pointer type" to key structures (struct key_ref *)
      that can have the bottom bit of the address set to indicate the possession of
      a key. This is propagated through searches from the keyring to the discovered
      key. It has been made a separate type so that the compiler can spot attempts
      to dereference a potentially incorrect pointer.
      
      The "possession" attribute can't be attached to a key structure directly as
      it's not an intrinsic property of a key.
      
      Pointers to keys have been replaced with struct key_ref *'s wherever
      possession information needs to be passed through.
      
      This does assume that the bottom bit of the pointer will always be zero on
      return from kmem_cache_alloc().
      
      The key reference type has been made into a typedef so that at least it can be
      located in the sources, even though it's basically a pointer to an undefined
      type. I've also renamed the accessor functions to be more useful, and all
      reference variables should now end in "_ref".
      Signed-Off-By: NDavid Howells <dhowells@redhat.com>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      664cceb0
  20. 05 8月, 2005 1 次提交
    • D
      [PATCH] Destruction of failed keyring oopses · 94efe72f
      David Howells 提交于
      The attached patch makes sure that a keyring that failed to instantiate
      properly is destroyed without oopsing [CAN-2005-2099].
      
      The problem occurs in three stages:
      
       (1) The key allocator initialises the type-specific data to all zeroes. In
           the case of a keyring, this will become a link in the keyring name list
           when the keyring is instantiated.
      
       (2) If a user (any user) attempts to add a keyring with anything other than
           an empty payload, the keyring instantiation function will fail with an
           error and won't add the keyring to the name list.
      
       (3) The keyring's destructor then sees that the keyring has a description
           (name) and tries to remove the keyring from the name list, which oopses
           because the link pointers are both zero.
      
      This bug permits any user to take down a box trivially.
      Signed-Off-By: NDavid Howells <dhowells@redhat.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      94efe72f
  21. 08 7月, 2005 1 次提交
  22. 24 6月, 2005 2 次提交
    • D
      [PATCH] Keys: Make request-key create an authorisation key · 3e30148c
      David Howells 提交于
      The attached patch makes the following changes:
      
       (1) There's a new special key type called ".request_key_auth".
      
           This is an authorisation key for when one process requests a key and
           another process is started to construct it. This type of key cannot be
           created by the user; nor can it be requested by kernel services.
      
           Authorisation keys hold two references:
      
           (a) Each refers to a key being constructed. When the key being
           	 constructed is instantiated the authorisation key is revoked,
           	 rendering it of no further use.
      
           (b) The "authorising process". This is either:
      
           	 (i) the process that called request_key(), or:
      
           	 (ii) if the process that called request_key() itself had an
           	      authorisation key in its session keyring, then the authorising
           	      process referred to by that authorisation key will also be
           	      referred to by the new authorisation key.
      
      	 This means that the process that initiated a chain of key requests
      	 will authorise the lot of them, and will, by default, wind up with
      	 the keys obtained from them in its keyrings.
      
       (2) request_key() creates an authorisation key which is then passed to
           /sbin/request-key in as part of a new session keyring.
      
       (3) When request_key() is searching for a key to hand back to the caller, if
           it comes across an authorisation key in the session keyring of the
           calling process, it will also search the keyrings of the process
           specified therein and it will use the specified process's credentials
           (fsuid, fsgid, groups) to do that rather than the calling process's
           credentials.
      
           This allows a process started by /sbin/request-key to find keys belonging
           to the authorising process.
      
       (4) A key can be read, even if the process executing KEYCTL_READ doesn't have
           direct read or search permission if that key is contained within the
           keyrings of a process specified by an authorisation key found within the
           calling process's session keyring, and is searchable using the
           credentials of the authorising process.
      
           This allows a process started by /sbin/request-key to read keys belonging
           to the authorising process.
      
       (5) The magic KEY_SPEC_*_KEYRING key IDs when passed to KEYCTL_INSTANTIATE or
           KEYCTL_NEGATE will specify a keyring of the authorising process, rather
           than the process doing the instantiation.
      
       (6) One of the process keyrings can be nominated as the default to which
           request_key() should attach new keys if not otherwise specified. This is
           done with KEYCTL_SET_REQKEY_KEYRING and one of the KEY_REQKEY_DEFL_*
           constants. The current setting can also be read using this call.
      
       (7) request_key() is partially interruptible. If it is waiting for another
           process to finish constructing a key, it can be interrupted. This permits
           a request-key cycle to be broken without recourse to rebooting.
      Signed-Off-By: NDavid Howells <dhowells@redhat.com>
      Signed-Off-By: NBenoit Boissinot <benoit.boissinot@ens-lyon.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      3e30148c
    • D
      [PATCH] keys: Discard key spinlock and use RCU for key payload · 76d8aeab
      David Howells 提交于
      The attached patch changes the key implementation in a number of ways:
      
       (1) It removes the spinlock from the key structure.
      
       (2) The key flags are now accessed using atomic bitops instead of
           write-locking the key spinlock and using C bitwise operators.
      
           The three instantiation flags are dealt with with the construction
           semaphore held during the request_key/instantiate/negate sequence, thus
           rendering the spinlock superfluous.
      
           The key flags are also now bit numbers not bit masks.
      
       (3) The key payload is now accessed using RCU. This permits the recursive
           keyring search algorithm to be simplified greatly since no locks need be
           taken other than the usual RCU preemption disablement. Searching now does
           not require any locks or semaphores to be held; merely that the starting
           keyring be pinned.
      
       (4) The keyring payload now includes an RCU head so that it can be disposed
           of by call_rcu(). This requires that the payload be copied on unlink to
           prevent introducing races in copy-down vs search-up.
      
       (5) The user key payload is now a structure with the data following it. It
           includes an RCU head like the keyring payload and for the same reason. It
           also contains a data length because the data length in the key may be
           changed on another CPU whilst an RCU protected read is in progress on the
           payload. This would then see the supposed RCU payload and the on-key data
           length getting out of sync.
      
           I'm tempted to drop the key's datalen entirely, except that it's used in
           conjunction with quota management and so is a little tricky to get rid
           of.
      
       (6) Update the keys documentation.
      Signed-Off-By: NDavid Howells <dhowells@redhat.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      76d8aeab
  23. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4