1. 13 3月, 2013 1 次提交
    • M
      Fix: compat_rw_copy_check_uvector() misuse in aio, readv, writev, and security keys · 8aec0f5d
      Mathieu Desnoyers 提交于
      Looking at mm/process_vm_access.c:process_vm_rw() and comparing it to
      compat_process_vm_rw() shows that the compatibility code requires an
      explicit "access_ok()" check before calling
      compat_rw_copy_check_uvector(). The same difference seems to appear when
      we compare fs/read_write.c:do_readv_writev() to
      fs/compat.c:compat_do_readv_writev().
      
      This subtle difference between the compat and non-compat requirements
      should probably be debated, as it seems to be error-prone. In fact,
      there are two others sites that use this function in the Linux kernel,
      and they both seem to get it wrong:
      
      Now shifting our attention to fs/aio.c, we see that aio_setup_iocb()
      also ends up calling compat_rw_copy_check_uvector() through
      aio_setup_vectored_rw(). Unfortunately, the access_ok() check appears to
      be missing. Same situation for
      security/keys/compat.c:compat_keyctl_instantiate_key_iov().
      
      I propose that we add the access_ok() check directly into
      compat_rw_copy_check_uvector(), so callers don't have to worry about it,
      and it therefore makes the compat call code similar to its non-compat
      counterpart. Place the access_ok() check in the same location where
      copy_from_user() can trigger a -EFAULT error in the non-compat code, so
      the ABI behaviors are alike on both compat and non-compat.
      
      While we are here, fix compat_do_readv_writev() so it checks for
      compat_rw_copy_check_uvector() negative return values.
      
      And also, fix a memory leak in compat_keyctl_instantiate_key_iov() error
      handling.
      Acked-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Acked-by: NAl Viro <viro@ZenIV.linux.org.uk>
      Signed-off-by: NMathieu Desnoyers <mathieu.desnoyers@efficios.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      8aec0f5d
  2. 12 3月, 2013 1 次提交
    • D
      keys: fix race with concurrent install_user_keyrings() · 0da9dfdd
      David Howells 提交于
      This fixes CVE-2013-1792.
      
      There is a race in install_user_keyrings() that can cause a NULL pointer
      dereference when called concurrently for the same user if the uid and
      uid-session keyrings are not yet created.  It might be possible for an
      unprivileged user to trigger this by calling keyctl() from userspace in
      parallel immediately after logging in.
      
      Assume that we have two threads both executing lookup_user_key(), both
      looking for KEY_SPEC_USER_SESSION_KEYRING.
      
      	THREAD A			THREAD B
      	===============================	===============================
      					==>call install_user_keyrings();
      	if (!cred->user->session_keyring)
      	==>call install_user_keyrings()
      					...
      					user->uid_keyring = uid_keyring;
      	if (user->uid_keyring)
      		return 0;
      	<==
      	key = cred->user->session_keyring [== NULL]
      					user->session_keyring = session_keyring;
      	atomic_inc(&key->usage); [oops]
      
      At the point thread A dereferences cred->user->session_keyring, thread B
      hasn't updated user->session_keyring yet, but thread A assumes it is
      populated because install_user_keyrings() returned ok.
      
      The race window is really small but can be exploited if, for example,
      thread B is interrupted or preempted after initializing uid_keyring, but
      before doing setting session_keyring.
      
      This couldn't be reproduced on a stock kernel.  However, after placing
      systemtap probe on 'user->session_keyring = session_keyring;' that
      introduced some delay, the kernel could be crashed reliably.
      
      Fix this by checking both pointers before deciding whether to return.
      Alternatively, the test could be done away with entirely as it is checked
      inside the mutex - but since the mutex is global, that may not be the best
      way.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Reported-by: NMateusz Guzik <mguzik@redhat.com>
      Cc: <stable@kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NJames Morris <james.l.morris@oracle.com>
      0da9dfdd
  3. 04 3月, 2013 1 次提交
    • E
      userns: Stop oopsing in key_change_session_keyring · ba0e3427
      Eric W. Biederman 提交于
      Dave Jones <davej@redhat.com> writes:
      > Just hit this on Linus' current tree.
      >
      > [   89.621770] BUG: unable to handle kernel NULL pointer dereference at 00000000000000c8
      > [   89.623111] IP: [<ffffffff810784b0>] commit_creds+0x250/0x2f0
      > [   89.624062] PGD 122bfd067 PUD 122bfe067 PMD 0
      > [   89.624901] Oops: 0000 [#1] PREEMPT SMP
      > [   89.625678] Modules linked in: caif_socket caif netrom bridge hidp 8021q garp stp mrp rose llc2 af_rxrpc phonet af_key binfmt_misc bnep l2tp_ppp can_bcm l2tp_core pppoe pppox can_raw scsi_transport_iscsi ppp_generic slhc nfnetlink can ipt_ULOG ax25 decnet irda nfc rds x25 crc_ccitt appletalk atm ipx p8023 psnap p8022 llc lockd sunrpc ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 xt_conntrack nf_conntrack ip6table_filter ip6_tables btusb bluetooth snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_pcm vhost_net snd_page_alloc snd_timer tun macvtap usb_debug snd rfkill microcode macvlan edac_core pcspkr serio_raw kvm_amd soundcore kvm r8169 mii
      > [   89.637846] CPU 2
      > [   89.638175] Pid: 782, comm: trinity-main Not tainted 3.8.0+ #63 Gigabyte Technology Co., Ltd. GA-MA78GM-S2H/GA-MA78GM-S2H
      > [   89.639850] RIP: 0010:[<ffffffff810784b0>]  [<ffffffff810784b0>] commit_creds+0x250/0x2f0
      > [   89.641161] RSP: 0018:ffff880115657eb8  EFLAGS: 00010207
      > [   89.641984] RAX: 00000000000003e8 RBX: ffff88012688b000 RCX: 0000000000000000
      > [   89.643069] RDX: 0000000000000000 RSI: ffffffff81c32960 RDI: ffff880105839600
      > [   89.644167] RBP: ffff880115657ed8 R08: 0000000000000000 R09: 0000000000000000
      > [   89.645254] R10: 0000000000000001 R11: 0000000000000246 R12: ffff880105839600
      > [   89.646340] R13: ffff88011beea490 R14: ffff88011beea490 R15: 0000000000000000
      > [   89.647431] FS:  00007f3ac063b740(0000) GS:ffff88012b200000(0000) knlGS:0000000000000000
      > [   89.648660] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
      > [   89.649548] CR2: 00000000000000c8 CR3: 0000000122bfc000 CR4: 00000000000007e0
      > [   89.650635] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      > [   89.651723] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      > [   89.652812] Process trinity-main (pid: 782, threadinfo ffff880115656000, task ffff88011beea490)
      > [   89.654128] Stack:
      > [   89.654433]  0000000000000000 ffff8801058396a0 ffff880105839600 ffff88011beeaa78
      > [   89.655769]  ffff880115657ef8 ffffffff812c7d9b ffffffff82079be0 0000000000000000
      > [   89.657073]  ffff880115657f28 ffffffff8106c665 0000000000000002 ffff880115657f58
      > [   89.658399] Call Trace:
      > [   89.658822]  [<ffffffff812c7d9b>] key_change_session_keyring+0xfb/0x140
      > [   89.659845]  [<ffffffff8106c665>] task_work_run+0xa5/0xd0
      > [   89.660698]  [<ffffffff81002911>] do_notify_resume+0x71/0xb0
      > [   89.661581]  [<ffffffff816c9a4a>] int_signal+0x12/0x17
      > [   89.662385] Code: 24 90 00 00 00 48 8b b3 90 00 00 00 49 8b 4c 24 40 48 39 f2 75 08 e9 83 00 00 00 48 89 ca 48 81 fa 60 29 c3 81 0f 84 41 fe ff ff <48> 8b 8a c8 00 00 00 48 39 ce 75 e4 3b 82 d0 00 00 00 0f 84 4b
      > [   89.667778] RIP  [<ffffffff810784b0>] commit_creds+0x250/0x2f0
      > [   89.668733]  RSP <ffff880115657eb8>
      > [   89.669301] CR2: 00000000000000c8
      >
      > My fastest trinity induced oops yet!
      >
      >
      > Appears to be..
      >
      >                 if ((set_ns == subset_ns->parent)  &&
      >      850:       48 8b 8a c8 00 00 00    mov    0xc8(%rdx),%rcx
      >
      > from the inlined cred_cap_issubset
      
      By historical accident we have been reading trying to set new->user_ns
      from new->user_ns.  Which is totally silly as new->user_ns is NULL (as
      is every other field in new except session_keyring at that point).
      
      The intent is clearly to copy all of the fields from old to new so copy
      old->user_ns into  into new->user_ns.
      
      Cc: stable@vger.kernel.org
      Reported-by: NDave Jones <davej@redhat.com>
      Tested-by: NDave Jones <davej@redhat.com>
      Acked-by: NSerge Hallyn <serge.hallyn@canonical.com>
      Signed-off-by: N"Eric W. Biederman" <ebiederm@xmission.com>
      ba0e3427
  4. 28 2月, 2013 2 次提交
    • S
      hlist: drop the node parameter from iterators · b67bfe0d
      Sasha Levin 提交于
      I'm not sure why, but the hlist for each entry iterators were conceived
      
              list_for_each_entry(pos, head, member)
      
      The hlist ones were greedy and wanted an extra parameter:
      
              hlist_for_each_entry(tpos, pos, head, member)
      
      Why did they need an extra pos parameter? I'm not quite sure. Not only
      they don't really need it, it also prevents the iterator from looking
      exactly like the list iterator, which is unfortunate.
      
      Besides the semantic patch, there was some manual work required:
      
       - Fix up the actual hlist iterators in linux/list.h
       - Fix up the declaration of other iterators based on the hlist ones.
       - A very small amount of places were using the 'node' parameter, this
       was modified to use 'obj->member' instead.
       - Coccinelle didn't handle the hlist_for_each_entry_safe iterator
       properly, so those had to be fixed up manually.
      
      The semantic patch which is mostly the work of Peter Senna Tschudin is here:
      
      @@
      iterator name hlist_for_each_entry, hlist_for_each_entry_continue, hlist_for_each_entry_from, hlist_for_each_entry_rcu, hlist_for_each_entry_rcu_bh, hlist_for_each_entry_continue_rcu_bh, for_each_busy_worker, ax25_uid_for_each, ax25_for_each, inet_bind_bucket_for_each, sctp_for_each_hentry, sk_for_each, sk_for_each_rcu, sk_for_each_from, sk_for_each_safe, sk_for_each_bound, hlist_for_each_entry_safe, hlist_for_each_entry_continue_rcu, nr_neigh_for_each, nr_neigh_for_each_safe, nr_node_for_each, nr_node_for_each_safe, for_each_gfn_indirect_valid_sp, for_each_gfn_sp, for_each_host;
      
      type T;
      expression a,c,d,e;
      identifier b;
      statement S;
      @@
      
      -T b;
          <+... when != b
      (
      hlist_for_each_entry(a,
      - b,
      c, d) S
      |
      hlist_for_each_entry_continue(a,
      - b,
      c) S
      |
      hlist_for_each_entry_from(a,
      - b,
      c) S
      |
      hlist_for_each_entry_rcu(a,
      - b,
      c, d) S
      |
      hlist_for_each_entry_rcu_bh(a,
      - b,
      c, d) S
      |
      hlist_for_each_entry_continue_rcu_bh(a,
      - b,
      c) S
      |
      for_each_busy_worker(a, c,
      - b,
      d) S
      |
      ax25_uid_for_each(a,
      - b,
      c) S
      |
      ax25_for_each(a,
      - b,
      c) S
      |
      inet_bind_bucket_for_each(a,
      - b,
      c) S
      |
      sctp_for_each_hentry(a,
      - b,
      c) S
      |
      sk_for_each(a,
      - b,
      c) S
      |
      sk_for_each_rcu(a,
      - b,
      c) S
      |
      sk_for_each_from
      -(a, b)
      +(a)
      S
      + sk_for_each_from(a) S
      |
      sk_for_each_safe(a,
      - b,
      c, d) S
      |
      sk_for_each_bound(a,
      - b,
      c) S
      |
      hlist_for_each_entry_safe(a,
      - b,
      c, d, e) S
      |
      hlist_for_each_entry_continue_rcu(a,
      - b,
      c) S
      |
      nr_neigh_for_each(a,
      - b,
      c) S
      |
      nr_neigh_for_each_safe(a,
      - b,
      c, d) S
      |
      nr_node_for_each(a,
      - b,
      c) S
      |
      nr_node_for_each_safe(a,
      - b,
      c, d) S
      |
      - for_each_gfn_sp(a, c, d, b) S
      + for_each_gfn_sp(a, c, d) S
      |
      - for_each_gfn_indirect_valid_sp(a, c, d, b) S
      + for_each_gfn_indirect_valid_sp(a, c, d) S
      |
      for_each_host(a,
      - b,
      c) S
      |
      for_each_host_safe(a,
      - b,
      c, d) S
      |
      for_each_mesh_entry(a,
      - b,
      c, d) S
      )
          ...+>
      
      [akpm@linux-foundation.org: drop bogus change from net/ipv4/raw.c]
      [akpm@linux-foundation.org: drop bogus hunk from net/ipv6/raw.c]
      [akpm@linux-foundation.org: checkpatch fixes]
      [akpm@linux-foundation.org: fix warnings]
      [akpm@linux-foudnation.org: redo intrusive kvm changes]
      Tested-by: NPeter Senna Tschudin <peter.senna@gmail.com>
      Acked-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Signed-off-by: NSasha Levin <sasha.levin@oracle.com>
      Cc: Wu Fengguang <fengguang.wu@intel.com>
      Cc: Marcelo Tosatti <mtosatti@redhat.com>
      Cc: Gleb Natapov <gleb@redhat.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      b67bfe0d
    • A
      45e09bd5
  5. 26 2月, 2013 2 次提交
  6. 25 2月, 2013 1 次提交
  7. 23 2月, 2013 1 次提交
  8. 22 2月, 2013 1 次提交
  9. 21 2月, 2013 1 次提交
    • D
      KEYS: Revert one application of "Fix unreachable code" patch · fe9453a1
      David Howells 提交于
      A patch to fix some unreachable code in search_my_process_keyrings() got
      applied twice by two different routes upstream as commits e67eab39
      and b010520a (both "fix unreachable code").
      
      Unfortunately, the second application removed something it shouldn't
      have and this wasn't detected by GIT.  This is due to the patch not
      having sufficient lines of context to distinguish the two places of
      application.
      
      The effect of this is relatively minor: inside the kernel, the keyring
      search routines may search multiple keyrings and then prioritise the
      errors if no keys or negative keys are found in any of them.  With the
      extra deletion, the presence of a negative key in the thread keyring
      (causing ENOKEY) is incorrectly overridden by an error searching the
      process keyring.
      
      So revert the second application of the patch.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Cc: Jiri Kosina <jkosina@suse.cz>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      fe9453a1
  10. 07 2月, 2013 1 次提交
    • D
      ima: digital signature verification using asymmetric keys · e0751257
      Dmitry Kasatkin 提交于
      Asymmetric keys were introduced in linux-3.7 to verify the signature on
      signed kernel modules. The asymmetric keys infrastructure abstracts the
      signature verification from the crypto details. This patch adds IMA/EVM
      signature verification using asymmetric keys. Support for additional
      signature verification methods can now be delegated to the asymmetric
      key infrastructure.
      
      Although the module signature header and the IMA/EVM signature header
      could use the same format, to minimize the signature length and save
      space in the extended attribute, this patch defines a new IMA/EVM
      header format.  The main difference is that the key identifier is a
      sha1[12 - 19] hash of the key modulus and exponent, similar to the
      current implementation.  The only purpose of the key identifier is to
      identify the corresponding key in the kernel keyring.  ima-evm-utils
      was updated to support the new signature format.
      
      While asymmetric signature verification functionality supports many
      different hash algorithms, the hash used in this patch is calculated
      during the IMA collection phase, based on the configured algorithm.
      The default algorithm is sha1, but for backwards compatibility md5
      is supported.  Due to this current limitation, signatures should be
      generated using a sha1 hash algorithm.
      
      Changes in this patch:
      - Functionality has been moved to separate source file in order to get rid of
        in source #ifdefs.
      - keyid is derived according to the RFC 3280. It does not require to assign
        IMA/EVM specific "description" when loading X509 certificate. Kernel
        asymmetric key subsystem automatically generate the description. Also
        loading a certificate does not require using of ima-evm-utils and can be
        done using keyctl only.
      - keyid size is reduced to 32 bits to save xattr space.  Key search is done
        using partial match functionality of asymmetric_key_match().
      - Kconfig option title was changed
      Signed-off-by: NDmitry Kasatkin <dmitry.kasatkin@intel.com>
      Acked-by: NDavid Howells <dhowells@redhat.com>
      Signed-off-by: NMimi Zohar <zohar@linux.vnet.ibm.com>
      e0751257
  11. 06 2月, 2013 4 次提交
    • D
      ima: rename hash calculation functions · 50af5544
      Dmitry Kasatkin 提交于
      Rename hash calculation functions to reflect meaning
      and change argument order in conventional way.
      Signed-off-by: NDmitry Kasatkin <dmitry.kasatkin@intel.com>
      Signed-off-by: NMimi Zohar <zohar@linux.vnet.ibm.com>
      50af5544
    • D
      ima: use new crypto_shash API instead of old crypto_hash · 76bb28f6
      Dmitry Kasatkin 提交于
      Old crypto hash API internally uses shash API.
      Using shash API directly is more efficient.
      Signed-off-by: NDmitry Kasatkin <dmitry.kasatkin@intel.com>
      Signed-off-by: NMimi Zohar <zohar@linux.vnet.ibm.com>
      76bb28f6
    • D
      ima: add policy support for file system uuid · 85865c1f
      Dmitry Kasatkin 提交于
      The IMA policy permits specifying rules to enable or disable
      measurement/appraisal/audit based on the file system magic number.
      If, for example, the policy contains an ext4 measurement rule,
      the rule is enabled for all ext4 partitions.
      
      Sometimes it might be necessary to enable measurement/appraisal/audit
      only for one partition and disable it for another partition of the
      same type.  With the existing IMA policy syntax, this can not be done.
      
      This patch provides support for IMA policy rules to specify the file
      system by its UUID (eg. fsuuid=397449cd-687d-4145-8698-7fed4a3e0363).
      
      For partitions not being appraised, it might be a good idea to mount
      file systems with the 'noexec' option to prevent executing non-verified
      binaries.
      Signed-off-by: NDmitry Kasatkin <dmitry.kasatkin@intel.com>
      Signed-off-by: NMimi Zohar <zohar@linux.vnet.ibm.com>
      85865c1f
    • D
      evm: add file system uuid to EVM hmac · 74de6684
      Dmitry Kasatkin 提交于
      EVM uses the same key for all file systems to calculate the HMAC,
      making it possible to paste inodes from one file system on to another
      one, without EVM being able to detect it.  To prevent such an attack,
      it is necessary to make the EVM HMAC file system specific.
      
      This patch uses the file system UUID, a file system unique identifier,
      to bind the EVM HMAC to the file system. The value inode->i_sb->s_uuid
      is used for the HMAC hash calculation, instead of using it for deriving
      the file system specific key.  Initializing the key for every inode HMAC
      calculation is a bit more expensive operation than adding the uuid to
      the HMAC hash.
      
      Changing the HMAC calculation method or adding additional info to the
      calculation, requires existing EVM labeled file systems to be relabeled.
      This patch adds a Kconfig HMAC version option for backwards compatability.
      
      Changelog v1:
      - squash "hmac version setting"
      Changelog v0:
      - add missing Kconfig depends (Mimi)
      Signed-off-by: NDmitry Kasatkin <dmitry.kasatkin@intel.com>
      Signed-off-by: NMimi Zohar <zohar@linux.vnet.ibm.com>
      74de6684
  12. 23 1月, 2013 4 次提交
  13. 21 1月, 2013 2 次提交
    • J
      security/device_cgroup: lock assert fails in dev_exception_clean() · 103a197c
      Jerry Snitselaar 提交于
      devcgroup_css_free() calls dev_exception_clean() without the devcgroup_mutex being locked.
      
      Shutting down a kvm virt was giving me the following trace:
      
      [36280.732764] ------------[ cut here ]------------
      [36280.732778] WARNING: at /home/snits/dev/linux/security/device_cgroup.c:172 dev_exception_clean+0xa9/0xc0()
      [36280.732782] Hardware name: Studio XPS 8100
      [36280.732785] Modules linked in: xt_REDIRECT fuse ebtable_nat ebtables ipt_MASQUERADE iptable_nat nf_nat_ipv4 nf_nat xt_CHECKSUM iptable_mangle bridge stp llc nf_conntrack_ipv4 ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 nf_defrag_ipv4 ip6table_filter it87 hwmon_vid xt_state nf_conntrack ip6_tables snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_seq coretemp snd_seq_device crc32c_intel snd_pcm snd_page_alloc snd_timer snd broadcom tg3 serio_raw i7core_edac edac_core ptp pps_core lpc_ich pcspkr mfd_core soundcore microcode i2c_i801 nfsd auth_rpcgss nfs_acl lockd vhost_net sunrpc tun macvtap macvlan kvm_intel kvm uinput binfmt_misc autofs4 usb_storage firewire_ohci firewire_core crc_itu_t radeon drm_kms_helper ttm
      [36280.732921] Pid: 933, comm: libvirtd Tainted: G        W    3.8.0-rc3-00307-g4c217de #1
      [36280.732922] Call Trace:
      [36280.732927]  [<ffffffff81044303>] warn_slowpath_common+0x93/0xc0
      [36280.732930]  [<ffffffff8104434a>] warn_slowpath_null+0x1a/0x20
      [36280.732932]  [<ffffffff812deaf9>] dev_exception_clean+0xa9/0xc0
      [36280.732934]  [<ffffffff812deb2a>] devcgroup_css_free+0x1a/0x30
      [36280.732938]  [<ffffffff810ccd76>] cgroup_diput+0x76/0x210
      [36280.732941]  [<ffffffff8119eac0>] d_delete+0x120/0x180
      [36280.732943]  [<ffffffff81195cff>] vfs_rmdir+0xef/0x130
      [36280.732945]  [<ffffffff81195e47>] do_rmdir+0x107/0x1c0
      [36280.732949]  [<ffffffff8132d17e>] ? trace_hardirqs_on_thunk+0x3a/0x3f
      [36280.732951]  [<ffffffff81198646>] sys_rmdir+0x16/0x20
      [36280.732954]  [<ffffffff8173bd82>] system_call_fastpath+0x16/0x1b
      [36280.732956] ---[ end trace ca39dced899a7d9f ]---
      Signed-off-by: NJerry Snitselaar <jerry.snitselaar@oracle.com>
      Cc: stable@kernel.org
      Signed-off-by: NJames Morris <james.l.morris@oracle.com>
      103a197c
    • D
      evm: checking if removexattr is not a NULL · a67adb99
      Dmitry Kasatkin 提交于
      The following lines of code produce a kernel oops.
      
      fd = socket(PF_FILE, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0);
      fchmod(fd, 0666);
      
      [  139.922364] BUG: unable to handle kernel NULL pointer dereference at   (null)
      [  139.924982] IP: [<  (null)>]   (null)
      [  139.924982] *pde = 00000000
      [  139.924982] Oops: 0000 [#5] SMP
      [  139.924982] Modules linked in: fuse dm_crypt dm_mod i2c_piix4 serio_raw evdev binfmt_misc button
      [  139.924982] Pid: 3070, comm: acpid Tainted: G      D      3.8.0-rc2-kds+ #465 Bochs Bochs
      [  139.924982] EIP: 0060:[<00000000>] EFLAGS: 00010246 CPU: 0
      [  139.924982] EIP is at 0x0
      [  139.924982] EAX: cf5ef000 EBX: cf5ef000 ECX: c143d600 EDX: c15225f2
      [  139.924982] ESI: cf4d2a1c EDI: cf4d2a1c EBP: cc02df10 ESP: cc02dee4
      [  139.924982]  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
      [  139.924982] CR0: 80050033 CR2: 00000000 CR3: 0c059000 CR4: 000006d0
      [  139.924982] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
      [  139.924982] DR6: ffff0ff0 DR7: 00000400
      [  139.924982] Process acpid (pid: 3070, ti=cc02c000 task=d7705340 task.ti=cc02c000)
      [  139.924982] Stack:
      [  139.924982]  c1203c88 00000000 cc02def4 cf4d2a1c ae21eefa 471b60d5 1083c1ba c26a5940
      [  139.924982]  e891fb5e 00000041 00000004 cc02df1c c1203964 00000000 cc02df4c c10e20c3
      [  139.924982]  00000002 00000000 00000000 22222222 c1ff2222 cf5ef000 00000000 d76efb08
      [  139.924982] Call Trace:
      [  139.924982]  [<c1203c88>] ? evm_update_evmxattr+0x5b/0x62
      [  139.924982]  [<c1203964>] evm_inode_post_setattr+0x22/0x26
      [  139.924982]  [<c10e20c3>] notify_change+0x25f/0x281
      [  139.924982]  [<c10cbf56>] chmod_common+0x59/0x76
      [  139.924982]  [<c10e27a1>] ? put_unused_fd+0x33/0x33
      [  139.924982]  [<c10cca09>] sys_fchmod+0x39/0x5c
      [  139.924982]  [<c13f4f30>] syscall_call+0x7/0xb
      [  139.924982] Code:  Bad EIP value.
      
      This happens because sockets do not define the removexattr operation.
      Before removing the xattr, verify the removexattr function pointer is
      not NULL.
      Signed-off-by: NDmitry Kasatkin <dmitry.kasatkin@intel.com>
      Signed-off-by: NMimi Zohar <zohar@linux.vnet.ibm.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NJames Morris <james.l.morris@oracle.com>
      a67adb99
  14. 17 1月, 2013 9 次提交
  15. 15 1月, 2013 2 次提交
    • P
      tun: fix LSM/SELinux labeling of tun/tap devices · 5dbbaf2d
      Paul Moore 提交于
      This patch corrects some problems with LSM/SELinux that were introduced
      with the multiqueue patchset.  The problem stems from the fact that the
      multiqueue work changed the relationship between the tun device and its
      associated socket; before the socket persisted for the life of the
      device, however after the multiqueue changes the socket only persisted
      for the life of the userspace connection (fd open).  For non-persistent
      devices this is not an issue, but for persistent devices this can cause
      the tun device to lose its SELinux label.
      
      We correct this problem by adding an opaque LSM security blob to the
      tun device struct which allows us to have the LSM security state, e.g.
      SELinux labeling information, persist for the lifetime of the tun
      device.  In the process we tweak the LSM hooks to work with this new
      approach to TUN device/socket labeling and introduce a new LSM hook,
      security_tun_dev_attach_queue(), to approve requests to attach to a
      TUN queue via TUNSETQUEUE.
      
      The SELinux code has been adjusted to match the new LSM hooks, the
      other LSMs do not make use of the LSM TUN controls.  This patch makes
      use of the recently added "tun_socket:attach_queue" permission to
      restrict access to the TUNSETQUEUE operation.  On older SELinux
      policies which do not define the "tun_socket:attach_queue" permission
      the access control decision for TUNSETQUEUE will be handled according
      to the SELinux policy's unknown permission setting.
      Signed-off-by: NPaul Moore <pmoore@redhat.com>
      Acked-by: NEric Paris <eparis@parisplace.org>
      Tested-by: NJason Wang <jasowang@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5dbbaf2d
    • P
      selinux: add the "attach_queue" permission to the "tun_socket" class · 6f96c142
      Paul Moore 提交于
      Add a new permission to align with the new TUN multiqueue support,
      "tun_socket:attach_queue".
      
      The corresponding SELinux reference policy patch is show below:
      
       diff --git a/policy/flask/access_vectors b/policy/flask/access_vectors
       index 28802c5..a0664a1 100644
       --- a/policy/flask/access_vectors
       +++ b/policy/flask/access_vectors
       @@ -827,6 +827,9 @@ class kernel_service
      
        class tun_socket
        inherits socket
       +{
       +       attach_queue
       +}
      
        class x_pointer
        inherits x_device
      Signed-off-by: NPaul Moore <pmoore@redhat.com>
      Acked-by: NEric Paris <eparis@parisplace.org>
      Tested-by: NJason Wang <jasowang@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6f96c142
  16. 24 12月, 2012 1 次提交
  17. 21 12月, 2012 1 次提交
  18. 16 12月, 2012 1 次提交
  19. 15 12月, 2012 3 次提交
    • E
      Fix cap_capable to only allow owners in the parent user namespace to have caps. · 520d9eab
      Eric W. Biederman 提交于
      Andy Lutomirski pointed out that the current behavior of allowing the
      owner of a user namespace to have all caps when that owner is not in a
      parent user namespace is wrong.  Add a test to ensure the owner of a user
      namespace is in the parent of the user namespace to fix this bug.
      
      Thankfully this bug did not apply to the initial user namespace, keeping
      the mischief that can be caused by this bug quite small.
      
      This is bug was introduced in v3.5 by commit 783291e6
      "Simplify the user_namespace by making userns->creator a kuid."
      But did not matter until the permisions required to create
      a user namespace were relaxed allowing a user namespace to be created
      inside of a user namespace.
      
      The bug made it possible for the owner of a user namespace to be
      present in a child user namespace.  Since the owner of a user nameapce
      is granted all capabilities it became possible for users in a
      grandchild user namespace to have all privilges over their parent user
      namspace.
      
      Reorder the checks in cap_capable.  This should make the common case
      faster and make it clear that nothing magic happens in the initial
      user namespace.  The reordering is safe because cred->user_ns
      can only be in targ_ns or targ_ns->parent but not both.
      
      Add a comment a the top of the loop to make the logic of
      the code clear.
      
      Add a distinct variable ns that changes as we walk up
      the user namespace hierarchy to make it clear which variable
      is changing.
      Acked-by: NSerge Hallyn <serge.hallyn@canonical.com>
      Signed-off-by: N"Eric W. Biederman" <ebiederm@xmission.com>
      520d9eab
    • C
      Smack: create a sysfs mount point for smackfs · e9307237
      Casey Schaufler 提交于
      There are a number of "conventions" for where to put LSM filesystems.
      Smack adheres to none of them. Create a mount point at /sys/fs/smackfs
      for mounting smackfs so that Smack can be conventional.
      
      Targeted for git://git.gitorious.org/smack-next/kernel.gitSigned-off-by: NCasey Schaufler <casey@schaufler-ca.com>
      e9307237
    • C
      Smack: use select not depends in Kconfig · 111fe8bd
      Casey Schaufler 提交于
      The components NETLABEL and SECURITY_NETWORK are required by
      Smack. Using "depends" in Kconfig hides the Smack option
      if the user hasn't figured out that they need to be enabled
      while using make menuconfig. Using select is a better choice.
      Because select is not recursive depends on NET and SECURITY
      are added. The reflects similar usage in TOMOYO and AppArmor.
      
      Targeted for git://git.gitorious.org/smack-next/kernel.gitSigned-off-by: NCasey Schaufler <casey@schaufler-ca.com>
      111fe8bd
  20. 14 12月, 2012 1 次提交
    • M
      ima: support new kernel module syscall · fdf90729
      Mimi Zohar 提交于
      With the addition of the new kernel module syscall, which defines two
      arguments - a file descriptor to the kernel module and a pointer to a NULL
      terminated string of module arguments - it is now possible to measure and
      appraise kernel modules like any other file on the file system.
      
      This patch adds support to measure and appraise kernel modules in an
      extensible and consistent manner.
      
      To support filesystems without extended attribute support, additional
      patches could pass the signature as the first parameter.
      Signed-off-by: NMimi Zohar <zohar@us.ibm.com>
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      fdf90729