1. 15 May, 2012 1 commit
  2. 11 May, 2012 7 commits
    • David Howells's avatar
      KEYS: Add invalidation support · fd75815f
      David Howells authored
      Add support for invalidating a key - which renders it immediately invisible to
      further searches and causes the garbage collector to immediately wake up,
      remove it from keyrings and then destroy it when it's no longer referenced.
      
      It's better not to do this with keyctl_revoke() as that marks the key to start
      returning -EKEYREVOKED to searches when what is actually desired is to have the
      key refetched.
      
      To invalidate a key the caller must be granted SEARCH permission by the key.
      This may be too strict.  It may be better to also permit invalidation if the
      caller has any of READ, WRITE or SETATTR permission.
      
      The primary use for this is to evict keys that are cached in special keyrings,
      such as the DNS resolver or an ID mapper.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      fd75815f
    • David Howells's avatar
      KEYS: Do LRU discard in full keyrings · 31d5a79d
      David Howells authored
      Do an LRU discard in keyrings that are full rather than returning ENFILE.  To
      perform this, a time_t is added to the key struct and updated by the creation
      of a link to a key and by a key being found as the result of a search.  At the
      completion of a successful search, the keyrings in the path between the root of
      the search and the first found link to it also have their last-used times
      updated.
      
      Note that discarding a link to a key from a keyring does not necessarily
      destroy the key as there may be references held by other places.
      
      An alternate discard method that might suffice is to perform FIFO discard from
      the keyring, using the spare 2-byte hole in the keylist header as the index of
      the next link to be discarded.
      
      This is useful when using a keyring as a cache for DNS results or foreign
      filesystem IDs.
      
      
      This can be tested by the following.  As root do:
      
      	echo 1000 >/proc/sys/kernel/keys/root_maxkeys
      
      	kr=`keyctl newring foo @s`
      	for ((i=0; i<2000; i++)); do keyctl add user a$i a $kr; done
      
      Without this patch ENFILE should be reported when the keyring fills up.  With
      this patch, the keyring discards keys in an LRU fashion.  Note that the stored
      LRU time has a granularity of 1s.
      
      After doing this, /proc/key-users can be observed and should show that most of
      the 2000 keys have been discarded:
      
      	[root@andromeda ~]# cat /proc/key-users
      	    0:   517 516/516 513/1000 5249/20000
      
      The "513/1000" here is the number of quota-accounted keys present for this user
      out of the maximum permitted.
      
      In /proc/keys, the keyring shows the number of keys it has and the number of
      slots it has allocated:
      
      	[root@andromeda ~]# grep foo /proc/keys
      	200c64c4 I--Q--     1 perm 3b3f0000     0     0 keyring   foo: 509/509
      
      The maximum is (PAGE_SIZE - header) / key pointer size.  That's typically 509
      on a 64-bit system and 1020 on a 32-bit system.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      31d5a79d
    • David Howells's avatar
      KEYS: Permit in-place link replacement in keyring list · 233e4735
      David Howells authored
      Make use of the previous patch that makes the garbage collector perform RCU
      synchronisation before destroying defunct keys.  Key pointers can now be
      replaced in-place without creating a new keyring payload and replacing the
      whole thing as the discarded keys will not be destroyed until all currently
      held RCU read locks are released.
      
      If the keyring payload space needs to be expanded or contracted, then a
      replacement will still need allocating, and the original will still have to be
      freed by RCU.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      233e4735
    • David Howells's avatar
      KEYS: Perform RCU synchronisation on keys prior to key destruction · 65d87fe6
      David Howells authored
      Make the keys garbage collector invoke synchronize_rcu() prior to destroying
      keys with a zero usage count.  This means that a key can be examined under the
      RCU read lock in the safe knowledge that it won't get deallocated until after
      the lock is released - even if its usage count becomes zero whilst we're
      looking at it.
      
      This is useful in keyring search vs key link.  Consider a keyring containing a
      link to a key.  That link can be replaced in-place in the keyring without
      requiring an RCU copy-and-replace on the keyring contents without breaking a
      search underway on that keyring when the displaced key is released, provided
      the key is actually destroyed only after the RCU read lock held by the search
      algorithm is released.
      
      This permits __key_link() to replace a key without having to reallocate the key
      payload.  A key gets replaced if a new key being linked into a keyring has the
      same type and description.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Acked-by: default avatarJeff Layton <jlayton@redhat.com>
      65d87fe6
    • David Howells's avatar
      KEYS: Announce key type (un)registration · 1eb1bcf5
      David Howells authored
      Announce the (un)registration of a key type in the core key code rather than
      in the callers.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Acked-by: default avatarMimi Zohar <zohar@us.ibm.com>
      1eb1bcf5
    • David Howells's avatar
      KEYS: Reorganise keys Makefile · 9f7ce8e2
      David Howells authored
      Reorganise the keys directory Makefile to put all the core bits together and
      the type-specific bits after.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Acked-by: default avatarMimi Zohar <zohar@us.ibm.com>
      9f7ce8e2
    • David Howells's avatar
      KEYS: Move the key config into security/keys/Kconfig · f0894940
      David Howells authored
      Move the key config into security/keys/Kconfig as there are going to be a lot
      of key-related options.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Acked-by: default avatarMimi Zohar <zohar@us.ibm.com>
      f0894940
  3. 23 Mar, 2012 1 commit
  4. 07 Mar, 2012 1 commit
  5. 01 Mar, 2012 1 commit
  6. 19 Jan, 2012 2 commits
  7. 18 Jan, 2012 1 commit
    • Jeff Layton's avatar
      keys: add a "logon" key type · 9f6ed2ca
      Jeff Layton authored
      For CIFS, we want to be able to store NTLM credentials (aka username
      and password) in the keyring. We do not, however want to allow users
      to fetch those keys back out of the keyring since that would be a
      security risk.
      
      Unfortunately, due to the nuances of key permission bits, it's not
      possible to do this. We need to grant search permissions so the kernel
      can find these keys, but that also implies permissions to read the
      payload.
      
      Resolve this by adding a new key_type. This key type is essentially
      the same as key_type_user, but does not define a .read op. This
      prevents the payload from ever being visible from userspace. This
      key type also vets the description to ensure that it's "qualified"
      by checking to ensure that it has a ':' in it that is preceded by
      other characters.
      Acked-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarJeff Layton <jlayton@redhat.com>
      Signed-off-by: default avatarSteve French <smfrench@gmail.com>
      9f6ed2ca
  8. 17 Jan, 2012 3 commits
  9. 16 Nov, 2011 4 commits
    • David Howells's avatar
      KEYS: Give key types their own lockdep class for key->sem · 7845bc39
      David Howells authored
      Give keys their own lockdep class to differentiate them from each other in case
      a key of one type has to refer to a key of another type.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Acked-by: default avatarMimi Zohar <zohar@us.ibm.com>
      Signed-off-by: default avatarJames Morris <jmorris@namei.org>
      7845bc39
    • Mimi Zohar's avatar
      encrypted-keys: module build fixes · 9c698987
      Mimi Zohar authored
      Encrypted keys are encrypted/decrypted using either a trusted or
      user-defined key type, which is referred to as the 'master' key.
      The master key may be of type trusted iff the trusted key is
      builtin or both the trusted key and encrypted keys are built as
      modules.  This patch resolves the build dependency problem.
      
      - Use "masterkey-$(CONFIG_TRUSTED_KEYS)-$(CONFIG_ENCRYPTED_KEYS)" construct
      to encapsulate the above logic. (Suggested by Dimtry Kasatkin.)
      - Fixing the encrypted-keys Makefile, results in a module name change
      from encrypted.ko to encrypted-keys.ko.
      - Add module dependency for request_trusted_key() definition
      Signed-off-by: default avatarMimi Zohar <zohar@us.ibm.com>
      9c698987
    • Mimi Zohar's avatar
      encrypted-keys: fix error return code · f4a0d5ab
      Mimi Zohar authored
      Fix request_master_key() error return code.
      Signed-off-by: default avatarMimi Zohar <zohar@us.ibm.com>
      f4a0d5ab
    • David Howells's avatar
      KEYS: Fix a NULL pointer deref in the user-defined key type · 9f35a33b
      David Howells authored
      Fix a NULL pointer deref in the user-defined key type whereby updating a
      negative key into a fully instantiated key will cause an oops to occur
      when the code attempts to free the non-existent old payload.
      
      This results in an oops that looks something like the following:
      
        BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
        IP: [<ffffffff81085fa1>] __call_rcu+0x11/0x13e
        PGD 3391d067 PUD 3894a067 PMD 0
        Oops: 0002 [#1] SMP
        CPU 1
        Pid: 4354, comm: keyctl Not tainted 3.1.0-fsdevel+ #1140                  /DG965RY
        RIP: 0010:[<ffffffff81085fa1>]  [<ffffffff81085fa1>] __call_rcu+0x11/0x13e
        RSP: 0018:ffff88003d591df8  EFLAGS: 00010246
        RAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000000000006e
        RDX: ffffffff8161d0c0 RSI: 0000000000000000 RDI: 0000000000000000
        RBP: ffff88003d591e18 R08: 0000000000000000 R09: ffffffff8152fa6c
        R10: 0000000000000000 R11: 0000000000000300 R12: ffff88003b8f9538
        R13: ffffffff8161d0c0 R14: ffff88003b8f9d50 R15: ffff88003c69f908
        FS:  00007f97eb18c720(0000) GS:ffff88003bd00000(0000) knlGS:0000000000000000
        CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
        CR2: 0000000000000008 CR3: 000000003d47a000 CR4: 00000000000006e0
        DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
        DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
        Process keyctl (pid: 4354, threadinfo ffff88003d590000, task ffff88003c78a040)
        Stack:
         ffff88003e0ffde0 ffff88003b8f9538 0000000000000001 ffff88003b8f9d50
         ffff88003d591e28 ffffffff810860f0 ffff88003d591e68 ffffffff8117bfea
         ffff88003d591e68 ffffffff00000000 ffff88003e0ffde1 ffff88003e0ffde0
        Call Trace:
         [<ffffffff810860f0>] call_rcu_sched+0x10/0x12
         [<ffffffff8117bfea>] user_update+0x8d/0xa2
         [<ffffffff8117723a>] key_create_or_update+0x236/0x270
         [<ffffffff811789b1>] sys_add_key+0x123/0x17e
         [<ffffffff813b84bb>] system_call_fastpath+0x16/0x1b
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Acked-by: default avatarJeff Layton <jlayton@redhat.com>
      Acked-by: default avatarNeil Horman <nhorman@redhat.com>
      Acked-by: default avatarSteve Dickson <steved@redhat.com>
      Acked-by: default avatarJames Morris <jmorris@namei.org>
      Cc: stable@kernel.org
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      9f35a33b
  10. 01 Nov, 2011 2 commits
    • Andy Shevchenko's avatar
      security: follow rename pack_hex_byte() to hex_byte_pack() · 02473119
      Andy Shevchenko authored
      There is no functional change.
      Signed-off-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Cc: Mimi Zohar <zohar@us.ibm.com>
      Cc: James Morris <jmorris@namei.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      02473119
    • Christopher Yeoh's avatar
      Cross Memory Attach · fcf63409
      Christopher Yeoh authored
      The basic idea behind cross memory attach is to allow MPI programs doing
      intra-node communication to do a single copy of the message rather than a
      double copy of the message via shared memory.
      
      The following patch attempts to achieve this by allowing a destination
      process, given an address and size from a source process, to copy memory
      directly from the source process into its own address space via a system
      call.  There is also a symmetrical ability to copy from the current
      process's address space into a destination process's address space.
      
      - Use of /proc/pid/mem has been considered, but there are issues with
        using it:
        - Does not allow for specifying iovecs for both src and dest, assuming
          preadv or pwritev was implemented either the area read from or
        written to would need to be contiguous.
        - Currently mem_read allows only processes who are currently
        ptrace'ing the target and are still able to ptrace the target to read
        from the target. This check could possibly be moved to the open call,
        but its not clear exactly what race this restriction is stopping
        (reason  appears to have been lost)
        - Having to send the fd of /proc/self/mem via SCM_RIGHTS on unix
        domain socket is a bit ugly from a userspace point of view,
        especially when you may have hundreds if not (eventually) thousands
        of processes  that all need to do this with each other
        - Doesn't allow for some future use of the interface we would like to
        consider adding in the future (see below)
        - Interestingly reading from /proc/pid/mem currently actually
        involves two copies! (But this could be fixed pretty easily)
      
      As mentioned previously use of vmsplice instead was considered, but has
      problems.  Since you need the reader and writer working co-operatively if
      the pipe is not drained then you block.  Which requires some wrapping to
      do non blocking on the send side or polling on the receive.  In all to all
      communication it requires ordering otherwise you can deadlock.  And in the
      example of many MPI tasks writing to one MPI task vmsplice serialises the
      copying.
      
      There are some cases of MPI collectives where even a single copy interface
      does not get us the performance gain we could.  For example in an
      MPI_Reduce rather than copy the data from the source we would like to
      instead use it directly in a mathops (say the reduce is doing a sum) as
      this would save us doing a copy.  We don't need to keep a copy of the data
      from the source.  I haven't implemented this, but I think this interface
      could in the future do all this through the use of the flags - eg could
      specify the math operation and type and the kernel rather than just
      copying the data would apply the specified operation between the source
      and destination and store it in the destination.
      
      Although we don't have a "second user" of the interface (though I've had
      some nibbles from people who may be interested in using it for intra
      process messaging which is not MPI).  This interface is something which
      hardware vendors are already doing for their custom drivers to implement
      fast local communication.  And so in addition to this being useful for
      OpenMPI it would mean the driver maintainers don't have to fix things up
      when the mm changes.
      
      There was some discussion about how much faster a true zero copy would
      go. Here's a link back to the email with some testing I did on that:
      
      http://marc.info/?l=linux-mm&m=130105930902915&w=2
      
      There is a basic man page for the proposed interface here:
      
      http://ozlabs.org/~cyeoh/cma/process_vm_readv.txt
      
      This has been implemented for x86 and powerpc, other architecture should
      mainly (I think) just need to add syscall numbers for the process_vm_readv
      and process_vm_writev. There are 32 bit compatibility versions for
      64-bit kernels.
      
      For arch maintainers there are some simple tests to be able to quickly
      verify that the syscalls are working correctly here:
      
      http://ozlabs.org/~cyeoh/cma/cma-test-20110718.tgzSigned-off-by: default avatarChris Yeoh <yeohc@au1.ibm.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: David Howells <dhowells@redhat.com>
      Cc: James Morris <jmorris@namei.org>
      Cc: <linux-man@vger.kernel.org>
      Cc: <linux-arch@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      fcf63409
  11. 21 Sep, 2011 2 commits
  12. 15 Sep, 2011 1 commit
  13. 14 Sep, 2011 2 commits
  14. 22 Aug, 2011 7 commits
    • David Howells's avatar
      KEYS: Correctly destroy key payloads when their keytype is removed · 0c061b57
      David Howells authored
      unregister_key_type() has code to mark a key as dead and make it unavailable in
      one loop and then destroy all those unavailable key payloads in the next loop.
      However, the loop to mark keys dead renders the key undetectable to the second
      loop by changing the key type pointer also.
      
      Fix this by the following means:
      
       (1) The key code has two garbage collectors: one deletes unreferenced keys and
           the other alters keyrings to delete links to old dead, revoked and expired
           keys.  They can end up holding each other up as both want to scan the key
           serial tree under spinlock.  Combine these into a single routine.
      
       (2) Move the dead key marking, dead link removal and dead key removal into the
           garbage collector as a three phase process running over the three cycles
           of the normal garbage collection procedure.  This is tracked by the
           KEY_GC_REAPING_DEAD_1, _2 and _3 state flags.
      
           unregister_key_type() then just unlinks the key type from the list, wakes
           up the garbage collector and waits for the third phase to complete.
      
       (3) Downgrade the key types sem in unregister_key_type() once it has deleted
           the key type from the list so that it doesn't block the keyctl() syscall.
      
       (4) Dead keys that cannot be simply removed in the third phase have their
           payloads destroyed with the key's semaphore write-locked to prevent
           interference by the keyctl() syscall.  There should be no in-kernel users
           of dead keys of that type by the point of unregistration, though keyctl()
           may be holding a reference.
      
       (5) Only perform timer recalculation in the GC if the timer actually expired.
           If it didn't, we'll get another cycle when it goes off - and if the key
           that actually triggered it has been removed, it's not a problem.
      
       (6) Only garbage collect link if the timer expired or if we're doing dead key
           clean up phase 2.
      
       (7) As only key_garbage_collector() is permitted to use rb_erase() on the key
           serial tree, it doesn't need to revalidate its cursor after dropping the
           spinlock as the node the cursor points to must still exist in the tree.
      
       (8) Drop the spinlock in the GC if there is contention on it or if we need to
           reschedule.  After dealing with that, get the spinlock again and resume
           scanning.
      
      This has been tested in the following ways:
      
       (1) Run the keyutils testsuite against it.
      
       (2) Using the AF_RXRPC and RxKAD modules to test keytype removal:
      
           Load the rxrpc_s key type:
      
      	# insmod /tmp/af-rxrpc.ko
      	# insmod /tmp/rxkad.ko
      
           Create a key (http://people.redhat.com/~dhowells/rxrpc/listen.c):
      
      	# /tmp/listen &
      	[1] 8173
      
           Find the key:
      
      	# grep rxrpc_s /proc/keys
      	091086e1 I--Q--     1 perm 39390000     0     0 rxrpc_s   52:2
      
           Link it to a session keyring, preferably one with a higher serial number:
      
      	# keyctl link 0x20e36251 @s
      
           Kill the process (the key should remain as it's linked to another place):
      
      	# fg
      	/tmp/listen
      	^C
      
           Remove the key type:
      
      	rmmod rxkad
      	rmmod af-rxrpc
      
           This can be made a more effective test by altering the following part of
           the patch:
      
      	if (unlikely(gc_state & KEY_GC_REAPING_DEAD_2)) {
      		/* Make sure everyone revalidates their keys if we marked a
      		 * bunch as being dead and make sure all keyring ex-payloads
      		 * are destroyed.
      		 */
      		kdebug("dead sync");
      		synchronize_rcu();
      
           To call synchronize_rcu() in GC phase 1 instead.  That causes that the
           keyring's old payload content to hang around longer until it's RCU
           destroyed - which usually happens after GC phase 3 is complete.  This
           allows the destroy_dead_key branch to be tested.
      Reported-by: default avatarBenjamin Coddington <bcodding@gmail.com>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarJames Morris <jmorris@namei.org>
      0c061b57
    • David Howells's avatar
      KEYS: The dead key link reaper should be non-reentrant · d199798b
      David Howells authored
      The dead key link reaper should be non-reentrant as it relies on global state
      to keep track of where it's got to when it returns to the work queue manager to
      give it some air.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarJames Morris <jmorris@namei.org>
      d199798b
    • David Howells's avatar
      KEYS: Make the key reaper non-reentrant · b072e9bc
      David Howells authored
      Make the key reaper non-reentrant by sticking it on the appropriate system work
      queue when we queue it.  This will allow it to have global state and drop
      locks.  It should probably be non-reentrant already as it may spend a long time
      holding the key serial spinlock, and so multiple entrants can spend long
      periods of time just sitting there spinning, waiting to get the lock.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarJames Morris <jmorris@namei.org>
      b072e9bc
    • David Howells's avatar
      KEYS: Move the unreferenced key reaper to the keys garbage collector file · 8bc16dea
      David Howells authored
      Move the unreferenced key reaper function to the keys garbage collector file
      as that's a more appropriate place with the dead key link reaper.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarJames Morris <jmorris@namei.org>
      8bc16dea
    • David Howells's avatar
      KEYS: __key_link() should use the RCU deref wrapper for keyring payloads · 6d528b08
      David Howells authored
      __key_link() should use the RCU deref wrapper rcu_dereference_locked_keyring()
      for accessing keyring payloads rather than calling rcu_dereference_protected()
      directly.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarJames Morris <jmorris@namei.org>
      6d528b08
    • David Howells's avatar
      KEYS: keyctl_get_keyring_ID() should create a session keyring if create flag set · 3ecf1b4f
      David Howells authored
      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 <stdio.h>
      	#include <stdlib.h>
      	#include <keyutils.h>
      	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: default avatarGreg Wettstein <greg@enjellic.com>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Tested-by: default avatarGreg Wettstein <greg@enjellic.com>
      Signed-off-by: default avatarJames Morris <jmorris@namei.org>
      3ecf1b4f
    • David Howells's avatar
      KEYS: If install_session_keyring() is given a keyring, it should install it · 99599537
      David Howells authored
      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 d84f4f99
      	Author: David Howells <dhowells@redhat.com>
      	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 <stdio.h>
      	#include <stdlib.h>
      	#include <keyutils.h>
      	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: default avatarGreg Wettstein <greg@enjellic.com>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Tested-by: default avatarGreg Wettstein <greg@enjellic.com>
      Signed-off-by: default avatarJames Morris <jmorris@namei.org>
      99599537
  15. 08 Jul, 2011 1 commit
  16. 27 Jun, 2011 4 commits