lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Message-ID: <alpine.LRH.2.20.1703021102140.5195@namei.org>
Date:   Thu, 2 Mar 2017 11:09:18 +1100 (AEDT)
From:   James Morris <jmorris@...ei.org>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
cc:     linux-security-module@...r.kernel.org,
        linux-kernel@...r.kernel.org, David Howells <dhowells@...hat.com>,
        Paul Moore <paul@...l-moore.com>
Subject: [GIT PULL] Security subsystem updates for 4.11 (#2)

Two fixes for the security subsystem:

1) Keys: split both rcu_dereference_key() and user_key_payload() into 
versions which can be called with or without holding the key semaphore.

2) SELinux: fix Android init(8) breakage due to new cgroup security 
labeling support when using older policy.

Please pull.

---
The following changes since commit 6053dc981449718d90a429933e99b441e1adaea6:

  Merge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux (2017-03-01 10:32:30 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git for-linus

David Howells (1):
      KEYS: Differentiate uses of rcu_dereference_key() and user_key_payload()

Stephen Smalley (1):
      selinux: wrap cgroup seclabel support with its own policy capability

 Documentation/security/keys.txt          |   17 +++++++++++++++--
 drivers/md/dm-crypt.c                    |    2 +-
 fs/cifs/connect.c                        |    2 +-
 fs/crypto/keyinfo.c                      |    2 +-
 fs/ecryptfs/ecryptfs_kernel.h            |    2 +-
 fs/fscache/object-list.c                 |    2 +-
 fs/nfs/nfs4idmap.c                       |    2 +-
 include/keys/user-type.h                 |    9 +++++++--
 include/linux/key.h                      |    5 ++++-
 lib/digsig.c                             |    2 +-
 net/dns_resolver/dns_query.c             |    4 ++--
 security/keys/dh.c                       |    2 +-
 security/keys/encrypted-keys/encrypted.c |    4 ++--
 security/keys/trusted.c                  |    4 ++--
 security/keys/user_defined.c             |    6 +++---
 security/selinux/hooks.c                 |    7 ++++---
 security/selinux/include/security.h      |    2 ++
 security/selinux/selinuxfs.c             |    3 ++-
 security/selinux/ss/services.c           |    4 ++++
 19 files changed, 55 insertions(+), 26 deletions(-)

---
commit 2651225b5ebcdde60f684c4db8ec7e9e3800a74f
Author: Stephen Smalley <sds@...ho.nsa.gov>
Date:   Tue Feb 28 10:35:56 2017 -0500

    selinux: wrap cgroup seclabel support with its own policy capability
    
    commit 1ea0ce40690dff38935538e8dab7b12683ded0d3 ("selinux: allow
    changing labels for cgroupfs") broke the Android init program,
    which looks up security contexts whenever creating directories
    and attempts to assign them via setfscreatecon().
    When creating subdirectories in cgroup mounts, this would previously
    be ignored since cgroup did not support userspace setting of security
    contexts.  However, after the commit, SELinux would attempt to honor
    the requested context on cgroup directories and fail due to permission
    denial.  Avoid breaking existing userspace/policy by wrapping this change
    with a conditional on a new cgroup_seclabel policy capability.  This
    preserves existing behavior until/unless a new policy explicitly enables
    this capability.
    
    Reported-by: John Stultz <john.stultz@...aro.org>
    Signed-off-by: Stephen Smalley <sds@...ho.nsa.gov>
    Signed-off-by: Paul Moore <paul@...l-moore.com>
    Signed-off-by: James Morris <james.l.morris@...cle.com>

commit 0837e49ab3fa8d903a499984575d71efee8097ce
Author: David Howells <dhowells@...hat.com>
Date:   Wed Mar 1 15:11:23 2017 +0000

    KEYS: Differentiate uses of rcu_dereference_key() and user_key_payload()
    
    rcu_dereference_key() and user_key_payload() are currently being used in
    two different, incompatible ways:
    
     (1) As a wrapper to rcu_dereference() - when only the RCU read lock used
         to protect the key.
    
     (2) As a wrapper to rcu_dereference_protected() - when the key semaphor is
         used to protect the key and the may be being modified.
    
    Fix this by splitting both of the key wrappers to produce:
    
     (1) RCU accessors for keys when caller has the key semaphore locked:
    
    	dereference_key_locked()
    	user_key_payload_locked()
    
     (2) RCU accessors for keys when caller holds the RCU read lock:
    
    	dereference_key_rcu()
    	user_key_payload_rcu()
    
    This should fix following warning in the NFS idmapper
    
      ===============================
      [ INFO: suspicious RCU usage. ]
      4.10.0 #1 Tainted: G        W
      -------------------------------
      ./include/keys/user-type.h:53 suspicious rcu_dereference_protected() usage!
      other info that might help us debug this:
      rcu_scheduler_active = 2, debug_locks = 0
      1 lock held by mount.nfs/5987:
        #0:  (rcu_read_lock){......}, at: [<d000000002527abc>] nfs_idmap_get_key+0x15c/0x420 [nfsv4]
      stack backtrace:
      CPU: 1 PID: 5987 Comm: mount.nfs Tainted: G        W       4.10.0 #1
      Call Trace:
        dump_stack+0xe8/0x154 (unreliable)
        lockdep_rcu_suspicious+0x140/0x190
        nfs_idmap_get_key+0x380/0x420 [nfsv4]
        nfs_map_name_to_uid+0x2a0/0x3b0 [nfsv4]
        decode_getfattr_attrs+0xfac/0x16b0 [nfsv4]
        decode_getfattr_generic.constprop.106+0xbc/0x150 [nfsv4]
        nfs4_xdr_dec_lookup_root+0xac/0xb0 [nfsv4]
        rpcauth_unwrap_resp+0xe8/0x140 [sunrpc]
        call_decode+0x29c/0x910 [sunrpc]
        __rpc_execute+0x140/0x8f0 [sunrpc]
        rpc_run_task+0x170/0x200 [sunrpc]
        nfs4_call_sync_sequence+0x68/0xa0 [nfsv4]
        _nfs4_lookup_root.isra.44+0xd0/0xf0 [nfsv4]
        nfs4_lookup_root+0xe0/0x350 [nfsv4]
        nfs4_lookup_root_sec+0x70/0xa0 [nfsv4]
        nfs4_find_root_sec+0xc4/0x100 [nfsv4]
        nfs4_proc_get_rootfh+0x5c/0xf0 [nfsv4]
        nfs4_get_rootfh+0x6c/0x190 [nfsv4]
        nfs4_server_common_setup+0xc4/0x260 [nfsv4]
        nfs4_create_server+0x278/0x3c0 [nfsv4]
        nfs4_remote_mount+0x50/0xb0 [nfsv4]
        mount_fs+0x74/0x210
        vfs_kern_mount+0x78/0x220
        nfs_do_root_mount+0xb0/0x140 [nfsv4]
        nfs4_try_mount+0x60/0x100 [nfsv4]
        nfs_fs_mount+0x5ec/0xda0 [nfs]
        mount_fs+0x74/0x210
        vfs_kern_mount+0x78/0x220
        do_mount+0x254/0xf70
        SyS_mount+0x94/0x100
        system_call+0x38/0xe0
    
    Reported-by: Jan Stancek <jstancek@...hat.com>
    Signed-off-by: David Howells <dhowells@...hat.com>
    Tested-by: Jan Stancek <jstancek@...hat.com>
    Signed-off-by: James Morris <james.l.morris@...cle.com>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ