1. 22 Oct, 2013 14 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 3 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