1. 22 Oct, 2013 3 commits
  2. 26 Sep, 2013 2 commits
    • Paul Moore's avatar
      selinux: correct locking in selinux_netlbl_socket_connect) · 42d64e1a
      Paul Moore authored
      The SELinux/NetLabel glue code has a locking bug that affects systems
      with NetLabel enabled, see the kernel error message below.  This patch
      corrects this problem by converting the bottom half socket lock to a
      more conventional, and correct for this call-path, lock_sock() call.
      
       ===============================
       [ INFO: suspicious RCU usage. ]
       3.11.0-rc3+ #19 Not tainted
       -------------------------------
       net/ipv4/cipso_ipv4.c:1928 suspicious rcu_dereference_protected() usage!
      
       other info that might help us debug this:
      
       rcu_scheduler_active = 1, debug_locks = 0
       2 locks held by ping/731:
        #0:  (slock-AF_INET/1){+.-...}, at: [...] selinux_netlbl_socket_connect
        #1:  (rcu_read_lock){.+.+..}, at: [<...>] netlbl_conn_setattr
      
       stack backtrace:
       CPU: 1 PID: 731 Comm: ping Not tainted 3.11.0-rc3+ #19
       Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
        0000000000000001 ffff88006f659d28 ffffffff81726b6a ffff88003732c500
        ffff88006f659d58 ffffffff810e4457 ffff88006b845a00 0000000000000000
        000000000000000c ffff880075aa2f50 ffff88006f659d90 ffffffff8169bec7
       Call Trace:
        [<ffffffff81726b6a>] dump_stack+0x54/0x74
        [<ffffffff810e4457>] lockdep_rcu_suspicious+0xe7/0x120
        [<ffffffff8169bec7>] cipso_v4_sock_setattr+0x187/0x1a0
        [<ffffffff8170f317>] netlbl_conn_setattr+0x187/0x190
        [<ffffffff8170f195>] ? netlbl_conn_setattr+0x5/0x190
        [<ffffffff8131ac9e>] selinux_netlbl_socket_connect+0xae/0xc0
        [<ffffffff81303025>] selinux_socket_connect+0x135/0x170
        [<ffffffff8119d127>] ? might_fault+0x57/0xb0
        [<ffffffff812fb146>] security_socket_connect+0x16/0x20
        [<ffffffff815d3ad3>] SYSC_connect+0x73/0x130
        [<ffffffff81739a85>] ? sysret_check+0x22/0x5d
        [<ffffffff810e5e2d>] ? trace_hardirqs_on_caller+0xfd/0x1c0
        [<ffffffff81373d4e>] ? trace_hardirqs_on_thunk+0x3a/0x3f
        [<ffffffff815d52be>] SyS_connect+0xe/0x10
        [<ffffffff81739a59>] system_call_fastpath+0x16/0x1b
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarPaul Moore <pmoore@redhat.com>
      42d64e1a
    • Duan Jiong's avatar
      7d1db4b2
  3. 25 Sep, 2013 21 commits
  4. 24 Sep, 2013 14 commits
    • David Howells's avatar
      KEYS: Add per-user_namespace registers for persistent per-UID kerberos caches · f36f8c75
      David Howells authored
      Add support for per-user_namespace registers of persistent per-UID kerberos
      caches held within the kernel.
      
      This allows the kerberos cache to be retained beyond the life of all a user's
      processes so that the user's cron jobs can work.
      
      The kerberos cache is envisioned as a keyring/key tree looking something like:
      
      	struct user_namespace
      	  \___ .krb_cache keyring		- The register
      		\___ _krb.0 keyring		- Root's Kerberos cache
      		\___ _krb.5000 keyring		- User 5000's Kerberos cache
      		\___ _krb.5001 keyring		- User 5001's Kerberos cache
      			\___ tkt785 big_key	- A ccache blob
      			\___ tkt12345 big_key	- Another ccache blob
      
      Or possibly:
      
      	struct user_namespace
      	  \___ .krb_cache keyring		- The register
      		\___ _krb.0 keyring		- Root's Kerberos cache
      		\___ _krb.5000 keyring		- User 5000's Kerberos cache
      		\___ _krb.5001 keyring		- User 5001's Kerberos cache
      			\___ tkt785 keyring	- A ccache
      				\___ krbtgt/REDHAT.COM@REDHAT.COM big_key
      				\___ http/REDHAT.COM@REDHAT.COM user
      				\___ afs/REDHAT.COM@REDHAT.COM user
      				\___ nfs/REDHAT.COM@REDHAT.COM user
      				\___ krbtgt/KERNEL.ORG@KERNEL.ORG big_key
      				\___ http/KERNEL.ORG@KERNEL.ORG big_key
      
      What goes into a particular Kerberos cache is entirely up to userspace.  Kernel
      support is limited to giving you the Kerberos cache keyring that you want.
      
      The user asks for their Kerberos cache by:
      
      	krb_cache = keyctl_get_krbcache(uid, dest_keyring);
      
      The uid is -1 or the user's own UID for the user's own cache or the uid of some
      other user's cache (requires CAP_SETUID).  This permits rpc.gssd or whatever to
      mess with the cache.
      
      The cache returned is a keyring named "_krb.<uid>" that the possessor can read,
      search, clear, invalidate, unlink from and add links to.  Active LSMs get a
      chance to rule on whether the caller is permitted to make a link.
      
      Each uid's cache keyring is created when it first accessed and is given a
      timeout that is extended each time this function is called so that the keyring
      goes away after a while.  The timeout is configurable by sysctl but defaults to
      three days.
      
      Each user_namespace struct gets a lazily-created keyring that serves as the
      register.  The cache keyrings are added to it.  This means that standard key
      search and garbage collection facilities are available.
      
      The user_namespace struct's register goes away when it does and anything left
      in it is then automatically gc'd.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Tested-by: default avatarSimo Sorce <simo@redhat.com>
      cc: Serge E. Hallyn <serge.hallyn@ubuntu.com>
      cc: Eric W. Biederman <ebiederm@xmission.com>
      f36f8c75
    • David Howells's avatar
      KEYS: Implement a big key type that can save to tmpfs · ab3c3587
      David Howells authored
      Implement a big key type that can save its contents to tmpfs and thus
      swapspace when memory is tight.  This is useful for Kerberos ticket caches.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Tested-by: default avatarSimo Sorce <simo@redhat.com>
      ab3c3587
    • David Howells's avatar
      KEYS: Expand the capacity of a keyring · b2a4df20
      David Howells authored
      Expand the capacity of a keyring to be able to hold a lot more keys by using
      the previously added associative array implementation.  Currently the maximum
      capacity is:
      
      	(PAGE_SIZE - sizeof(header)) / sizeof(struct key *)
      
      which, on a 64-bit system, is a little more 500.  However, since this is being
      used for the NFS uid mapper, we need more than that.  The new implementation
      gives us effectively unlimited capacity.
      
      With some alterations, the keyutils testsuite runs successfully to completion
      after this patch is applied.  The alterations are because (a) keyrings that
      are simply added to no longer appear ordered and (b) some of the errors have
      changed a bit.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      b2a4df20
    • David Howells's avatar
      Add a generic associative array implementation. · 3cb98950
      David Howells authored
      Add a generic associative array implementation that can be used as the
      container for keyrings, thereby massively increasing the capacity available
      whilst also speeding up searching in keyrings that contain a lot of keys.
      
      This may also be useful in FS-Cache for tracking cookies.
      
      Documentation is added into Documentation/associative_array.txt
      
      Some of the properties of the implementation are:
      
       (1) Objects are opaque pointers.  The implementation does not care where they
           point (if anywhere) or what they point to (if anything).
      
           [!] NOTE: Pointers to objects _must_ be zero in the two least significant
           	       bits.
      
       (2) Objects do not need to contain linkage blocks for use by the array.  This
           permits an object to be located in multiple arrays simultaneously.
           Rather, the array is made up of metadata blocks that point to objects.
      
       (3) Objects are labelled as being one of two types (the type is a bool value).
           This information is stored in the array, but has no consequence to the
           array itself or its algorithms.
      
       (4) Objects require index keys to locate them within the array.
      
       (5) Index keys must be unique.  Inserting an object with the same key as one
           already in the array will replace the old object.
      
       (6) Index keys can be of any length and can be of different lengths.
      
       (7) Index keys should encode the length early on, before any variation due to
           length is seen.
      
       (8) Index keys can include a hash to scatter objects throughout the array.
      
       (9) The array can iterated over.  The objects will not necessarily come out in
           key order.
      
      (10) The array can be iterated whilst it is being modified, provided the RCU
           readlock is being held by the iterator.  Note, however, under these
           circumstances, some objects may be seen more than once.  If this is a
           problem, the iterator should lock against modification.  Objects will not
           be missed, however, unless deleted.
      
      (11) Objects in the array can be looked up by means of their index key.
      
      (12) Objects can be looked up whilst the array is being modified, provided the
           RCU readlock is being held by the thread doing the look up.
      
      The implementation uses a tree of 16-pointer nodes internally that are indexed
      on each level by nibbles from the index key.  To improve memory efficiency,
      shortcuts can be emplaced to skip over what would otherwise be a series of
      single-occupancy nodes.  Further, nodes pack leaf object pointers into spare
      space in the node rather than making an extra branch until as such time an
      object needs to be added to a full node.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      3cb98950
    • David Howells's avatar
      KEYS: Drop the permissions argument from __keyring_search_one() · e57e8669
      David Howells authored
      Drop the permissions argument from __keyring_search_one() as the only caller
      passes 0 here - which causes all checks to be skipped.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      e57e8669
    • David Howells's avatar
      KEYS: Define a __key_get() wrapper to use rather than atomic_inc() · ccc3e6d9
      David Howells authored
      Define a __key_get() wrapper to use rather than atomic_inc() on the key usage
      count as this makes it easier to hook in refcount error debugging.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      ccc3e6d9
    • David Howells's avatar
      KEYS: Search for auth-key by name rather than target key ID · d0a059ca
      David Howells authored
      Search for auth-key by name rather than by target key ID as, in a future
      patch, we'll by searching directly by index key in preference to iteration
      over all keys.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      d0a059ca
    • David Howells's avatar
      KEYS: Introduce a search context structure · 4bdf0bc3
      David Howells authored
      Search functions pass around a bunch of arguments, each of which gets copied
      with each call.  Introduce a search context structure to hold these.
      
      Whilst we're at it, create a search flag that indicates whether the search
      should be directly to the description or whether it should iterate through all
      keys looking for a non-description match.
      
      This will be useful when keyrings use a generic data struct with generic
      routines to manage their content as the search terms can just be passed
      through to the iterator callback function.
      
      Also, for future use, the data to be supplied to the match function is
      separated from the description pointer in the search context.  This makes it
      clear which is being supplied.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      4bdf0bc3
    • David Howells's avatar
      KEYS: Consolidate the concept of an 'index key' for key access · 16feef43
      David Howells authored
      Consolidate the concept of an 'index key' for accessing keys.  The index key
      is the search term needed to find a key directly - basically the key type and
      the key description.  We can add to that the description length.
      
      This will be useful when turning a keyring into an associative array rather
      than just a pointer block.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      16feef43
    • David Howells's avatar
      KEYS: key_is_dead() should take a const key pointer argument · 7e55ca6d
      David Howells authored
      key_is_dead() should take a const key pointer argument as it doesn't modify
      what it points to.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      7e55ca6d
    • David Howells's avatar
      KEYS: Use bool in make_key_ref() and is_key_possessed() · a5b4bd28
      David Howells authored
      Make make_key_ref() take a bool possession parameter and make
      is_key_possessed() return a bool.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      a5b4bd28
    • David Howells's avatar
      KEYS: Skip key state checks when checking for possession · 61ea0c0b
      David Howells authored
      Skip key state checks (invalidation, revocation and expiration) when checking
      for possession.  Without this, keys that have been marked invalid, revoked
      keys and expired keys are not given a possession attribute - which means the
      possessor is not granted any possession permits and cannot do anything with
      them unless they also have one a user, group or other permit.
      
      This causes failures in the keyutils test suite's revocation and expiration
      tests now that commit 96b5c8fe reduced the
      initial permissions granted to a key.
      
      The failures are due to accesses to revoked and expired keys being given
      EACCES instead of EKEYREVOKED or EKEYEXPIRED.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      61ea0c0b
    • Paul Moore's avatar
    • Eric Paris's avatar
      security: remove erroneous comment about capabilities.o link ordering · a3c9e45d
      Eric Paris authored
      Back when we had half ass LSM stacking we had to link capabilities.o
      after bigger LSMs so that on initialization the bigger LSM would
      register first and the capabilities module would be the one stacked as
      the 'seconday'.  Somewhere around 6f0f0fd4 (back in 2008) we
      finally removed the last of the kinda module stacking code but this
      comment in the makefile still lives today.
      Reported-by: default avatarValdis Kletnieks <Valdis.Kletnieks@vt.edu>
      Signed-off-by: default avatarEric Paris <eparis@redhat.com>
      Signed-off-by: default avatarJames Morris <james.l.morris@oracle.com>
      a3c9e45d