1. 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
  2. 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
  3. 24 12月, 2012 1 次提交
  4. 21 12月, 2012 1 次提交
  5. 16 12月, 2012 1 次提交
  6. 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
  7. 14 12月, 2012 2 次提交
  8. 11 12月, 2012 1 次提交
  9. 08 12月, 2012 1 次提交
    • C
      bridge: export multicast database via netlink · ee07c6e7
      Cong Wang 提交于
      V5: fix two bugs pointed out by Thomas
          remove seq check for now, mark it as TODO
      
      V4: remove some useless #include
          some coding style fix
      
      V3: drop debugging printk's
          update selinux perm table as well
      
      V2: drop patch 1/2, export ifindex directly
          Redesign netlink attributes
          Improve netlink seq check
          Handle IPv6 addr as well
      
      This patch exports bridge multicast database via netlink
      message type RTM_GETMDB. Similar to fdb, but currently bridge-specific.
      We may need to support modify multicast database too (RTM_{ADD,DEL}MDB).
      
      (Thanks to Thomas for patient reviews)
      
      Cc: Herbert Xu <herbert@gondor.apana.org.au>
      Cc: Stephen Hemminger <shemminger@vyatta.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Thomas Graf <tgraf@suug.ch>
      Cc: Jesper Dangaard Brouer <brouer@redhat.com>
      Signed-off-by: NCong Wang <amwang@redhat.com>
      Acked-by: NThomas Graf <tgraf@suug.ch>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ee07c6e7
  10. 21 11月, 2012 3 次提交
  11. 20 11月, 2012 2 次提交
  12. 07 11月, 2012 2 次提交
    • T
      device_cgroup: add lockdep asserts · 4b1c7840
      Tejun Heo 提交于
      device_cgroup uses RCU safe ->exceptions list which is write-protected
      by devcgroup_mutex and has had some issues using locking correctly.
      Add lockdep asserts to utility functions so that future errors can be
      easily detected.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Acked-by: NSerge E. Hallyn <serge.hallyn@ubuntu.com>
      Cc: Aristeu Rozanski <aris@redhat.com>
      Cc: Li Zefan <lizefan@huawei.com>
      4b1c7840
    • T
      device_cgroup: fix RCU usage · 201e72ac
      Tejun Heo 提交于
      dev_cgroup->exceptions is protected with devcgroup_mutex for writes
      and RCU for reads; however, RCU usage isn't correct.
      
      * dev_exception_clean() doesn't use RCU variant of list_del() and
        kfree().  The function can race with may_access() and may_access()
        may end up dereferencing already freed memory.  Use list_del_rcu()
        and kfree_rcu() instead.
      
      * may_access() may be called only with RCU read locked but doesn't use
        RCU safe traversal over ->exceptions.  Use list_for_each_entry_rcu().
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Acked-by: NSerge E. Hallyn <serge.hallyn@ubuntu.com>
      Cc: stable@vger.kernel.org
      Cc: Aristeu Rozanski <aris@redhat.com>
      Cc: Li Zefan <lizefan@huawei.com>
      201e72ac
  13. 06 11月, 2012 1 次提交
  14. 26 10月, 2012 5 次提交
  15. 24 10月, 2012 1 次提交
  16. 18 10月, 2012 1 次提交
  17. 17 10月, 2012 1 次提交
    • A
      fix a leak in replace_fd() users · 45525b26
      Al Viro 提交于
      replace_fd() began with "eats a reference, tries to insert into
      descriptor table" semantics; at some point I'd switched it to
      much saner current behaviour ("try to insert into descriptor
      table, grabbing a new reference if inserted; caller should do
      fput() in any case"), but forgot to update the callers.
      Mea culpa...
      
      [Spotted by Pavel Roskin, who has really weird system with pipe-fed
      coredumps as part of what he considers a normal boot ;-)]
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      45525b26
  18. 12 10月, 2012 1 次提交
  19. 09 10月, 2012 2 次提交
    • K
      mm: kill vma flag VM_RESERVED and mm->reserved_vm counter · 314e51b9
      Konstantin Khlebnikov 提交于
      A long time ago, in v2.4, VM_RESERVED kept swapout process off VMA,
      currently it lost original meaning but still has some effects:
      
       | effect                 | alternative flags
      -+------------------------+---------------------------------------------
      1| account as reserved_vm | VM_IO
      2| skip in core dump      | VM_IO, VM_DONTDUMP
      3| do not merge or expand | VM_IO, VM_DONTEXPAND, VM_HUGETLB, VM_PFNMAP
      4| do not mlock           | VM_IO, VM_DONTEXPAND, VM_HUGETLB, VM_PFNMAP
      
      This patch removes reserved_vm counter from mm_struct.  Seems like nobody
      cares about it, it does not exported into userspace directly, it only
      reduces total_vm showed in proc.
      
      Thus VM_RESERVED can be replaced with VM_IO or pair VM_DONTEXPAND | VM_DONTDUMP.
      
      remap_pfn_range() and io_remap_pfn_range() set VM_IO|VM_DONTEXPAND|VM_DONTDUMP.
      remap_vmalloc_range() set VM_DONTEXPAND | VM_DONTDUMP.
      
      [akpm@linux-foundation.org: drivers/vfio/pci/vfio_pci.c fixup]
      Signed-off-by: NKonstantin Khlebnikov <khlebnikov@openvz.org>
      Cc: Alexander Viro <viro@zeniv.linux.org.uk>
      Cc: Carsten Otte <cotte@de.ibm.com>
      Cc: Chris Metcalf <cmetcalf@tilera.com>
      Cc: Cyrill Gorcunov <gorcunov@openvz.org>
      Cc: Eric Paris <eparis@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Hugh Dickins <hughd@google.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: James Morris <james.l.morris@oracle.com>
      Cc: Jason Baron <jbaron@redhat.com>
      Cc: Kentaro Takeda <takedakn@nttdata.co.jp>
      Cc: Matt Helsley <matthltc@us.ibm.com>
      Cc: Nick Piggin <npiggin@kernel.dk>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Robert Richter <robert.richter@amd.com>
      Cc: Suresh Siddha <suresh.b.siddha@intel.com>
      Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      Cc: Venkatesh Pallipadi <venki@google.com>
      Acked-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      314e51b9
    • K
      mm: use mm->exe_file instead of first VM_EXECUTABLE vma->vm_file · 2dd8ad81
      Konstantin Khlebnikov 提交于
      Some security modules and oprofile still uses VM_EXECUTABLE for retrieving
      a task's executable file.  After this patch they will use mm->exe_file
      directly.  mm->exe_file is protected with mm->mmap_sem, so locking stays
      the same.
      Signed-off-by: NKonstantin Khlebnikov <khlebnikov@openvz.org>
      Acked-by: Chris Metcalf <cmetcalf@tilera.com>			[arch/tile]
      Acked-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>	[tomoyo]
      Cc: Alexander Viro <viro@zeniv.linux.org.uk>
      Cc: Carsten Otte <cotte@de.ibm.com>
      Cc: Cyrill Gorcunov <gorcunov@openvz.org>
      Cc: Eric Paris <eparis@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Hugh Dickins <hughd@google.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Acked-by: NJames Morris <james.l.morris@oracle.com>
      Cc: Jason Baron <jbaron@redhat.com>
      Cc: Kentaro Takeda <takedakn@nttdata.co.jp>
      Cc: Matt Helsley <matthltc@us.ibm.com>
      Cc: Nick Piggin <npiggin@kernel.dk>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Robert Richter <robert.richter@amd.com>
      Cc: Suresh Siddha <suresh.b.siddha@intel.com>
      Cc: Venkatesh Pallipadi <venki@google.com>
      Acked-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      2dd8ad81
  20. 08 10月, 2012 1 次提交
    • D
      KEYS: Add payload preparsing opportunity prior to key instantiate or update · cf7f601c
      David Howells 提交于
      Give the key type the opportunity to preparse the payload prior to the
      instantiation and update routines being called.  This is done with the
      provision of two new key type operations:
      
      	int (*preparse)(struct key_preparsed_payload *prep);
      	void (*free_preparse)(struct key_preparsed_payload *prep);
      
      If the first operation is present, then it is called before key creation (in
      the add/update case) or before the key semaphore is taken (in the update and
      instantiate cases).  The second operation is called to clean up if the first
      was called.
      
      preparse() is given the opportunity to fill in the following structure:
      
      	struct key_preparsed_payload {
      		char		*description;
      		void		*type_data[2];
      		void		*payload;
      		const void	*data;
      		size_t		datalen;
      		size_t		quotalen;
      	};
      
      Before the preparser is called, the first three fields will have been cleared,
      the payload pointer and size will be stored in data and datalen and the default
      quota size from the key_type struct will be stored into quotalen.
      
      The preparser may parse the payload in any way it likes and may store data in
      the type_data[] and payload fields for use by the instantiate() and update()
      ops.
      
      The preparser may also propose a description for the key by attaching it as a
      string to the description field.  This can be used by passing a NULL or ""
      description to the add_key() system call or the key_create_or_update()
      function.  This cannot work with request_key() as that required the description
      to tell the upcall about the key to be created.
      
      This, for example permits keys that store PGP public keys to generate their own
      name from the user ID and public key fingerprint in the key.
      
      The instantiate() and update() operations are then modified to look like this:
      
      	int (*instantiate)(struct key *key, struct key_preparsed_payload *prep);
      	int (*update)(struct key *key, struct key_preparsed_payload *prep);
      
      and the new payload data is passed in *prep, whether or not it was preparsed.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      cf7f601c
  21. 06 10月, 2012 4 次提交
  22. 05 10月, 2012 2 次提交
新手
引导
客服 返回
顶部