1. 13 8月, 2015 2 次提交
    • E
      userns,pidns: Force thread group sharing, not signal handler sharing. · faf00da5
      Eric W. Biederman 提交于
      The code that places signals in signal queues computes the uids, gids,
      and pids at the time the signals are enqueued.  Which means that tasks
      that share signal queues must be in the same pid and user namespaces.
      
      Sharing signal handlers is fine, but bizarre.
      
      So make the code in fork and userns_install clearer by only testing
      for what is functionally necessary.
      
      Also update the comment in unshare about unsharing a user namespace to
      be a little more explicit and make a little more sense.
      Acked-by: NOleg Nesterov <oleg@redhat.com>
      Signed-off-by: N"Eric W. Biederman" <ebiederm@xmission.com>
      faf00da5
    • E
      unshare: Unsharing a thread does not require unsharing a vm · 12c641ab
      Eric W. Biederman 提交于
      In the logic in the initial commit of unshare made creating a new
      thread group for a process, contingent upon creating a new memory
      address space for that process.  That is wrong.  Two separate
      processes in different thread groups can share a memory address space
      and clone allows creation of such proceses.
      
      This is significant because it was observed that mm_users > 1 does not
      mean that a process is multi-threaded, as reading /proc/PID/maps
      temporarily increments mm_users, which allows other processes to
      (accidentally) interfere with unshare() calls.
      
      Correct the check in check_unshare_flags() to test for
      !thread_group_empty() for CLONE_THREAD, CLONE_SIGHAND, and CLONE_VM.
      For sighand->count > 1 for CLONE_SIGHAND and CLONE_VM.
      For !current_is_single_threaded instead of mm_users > 1 for CLONE_VM.
      
      By using the correct checks in unshare this removes the possibility of
      an accidental denial of service attack.
      
      Additionally using the correct checks in unshare ensures that only an
      explicit unshare(CLONE_VM) can possibly trigger the slow path of
      current_is_single_threaded().  As an explict unshare(CLONE_VM) is
      pointless it is not expected there are many applications that make
      that call.
      
      Cc: stable@vger.kernel.org
      Fixes: b2e0d987 userns: Implement unshare of the user namespace
      Reported-by: NRicky Zhou <rickyz@chromium.org>
      Reported-by: NKees Cook <keescook@chromium.org>
      Reviewed-by: NKees Cook <keescook@chromium.org>
      Signed-off-by: N"Eric W. Biederman" <ebiederm@xmission.com>
      12c641ab
  2. 12 7月, 2015 1 次提交
  3. 10 7月, 2015 2 次提交
    • E
      mnt: fs_fully_visible enforce noexec and nosuid if !SB_I_NOEXEC · 77b1a97d
      Eric W. Biederman 提交于
      The filesystems proc and sysfs do not have executable files do not
      have exectuable files today and portions of userspace break if we do
      enforce nosuid and noexec consistency of nosuid and noexec flags
      between previous mounts and new mounts of proc and sysfs.
      
      Add the code to enforce consistency of the nosuid and noexec flags,
      and use the presence of SB_I_NOEXEC to signal that there is no need to
      bother.
      
      This results in a completely userspace invisible change that makes it
      clear fs_fully_visible can only skip the enforcement of noexec and
      nosuid because it is known the filesystems in question do not support
      executables.
      Signed-off-by: N"Eric W. Biederman" <ebiederm@xmission.com>
      77b1a97d
    • E
      vfs: Commit to never having exectuables on proc and sysfs. · 90f8572b
      Eric W. Biederman 提交于
      Today proc and sysfs do not contain any executable files.  Several
      applications today mount proc or sysfs without noexec and nosuid and
      then depend on there being no exectuables files on proc or sysfs.
      Having any executable files show on proc or sysfs would cause
      a user space visible regression, and most likely security problems.
      
      Therefore commit to never allowing executables on proc and sysfs by
      adding a new flag to mark them as filesystems without executables and
      enforce that flag.
      
      Test the flag where MNT_NOEXEC is tested today, so that the only user
      visible effect will be that exectuables will be treated as if the
      execute bit is cleared.
      
      The filesystems proc and sysfs do not currently incoporate any
      executable files so this does not result in any user visible effects.
      
      This makes it unnecessary to vet changes to proc and sysfs tightly for
      adding exectuable files or changes to chattr that would modify
      existing files, as no matter what the individual file say they will
      not be treated as exectuable files by the vfs.
      
      Not having to vet changes to closely is important as without this we
      are only one proc_create call (or another goof up in the
      implementation of notify_change) from having problematic executables
      on proc.  Those mistakes are all too easy to make and would create
      a situation where there are security issues or the assumptions of
      some program having to be broken (and cause userspace regressions).
      Signed-off-by: N"Eric W. Biederman" <ebiederm@xmission.com>
      90f8572b
  4. 06 7月, 2015 2 次提交
    • L
      Linux 4.2-rc1 · d770e558
      Linus Torvalds 提交于
      d770e558
    • L
      Merge tag 'platform-drivers-x86-v4.2-2' of... · a585d2b7
      Linus Torvalds 提交于
      Merge tag 'platform-drivers-x86-v4.2-2' of git://git.infradead.org/users/dvhart/linux-platform-drivers-x86
      
      Pull late x86 platform driver updates from Darren Hart:
       "The following came in a bit later and I wanted them to bake in next a
        few more days before submitting, thus the second pull.
      
        A new intel_pmc_ipc driver, a symmetrical allocation and free fix in
        dell-laptop, a couple minor fixes, and some updated documentation in
        the dell-laptop comments.
      
        intel_pmc_ipc:
         - Add Intel Apollo Lake PMC IPC driver
      
        tc1100-wmi:
         - Delete an unnecessary check before the function call "kfree"
      
        dell-laptop:
         - Fix allocating & freeing SMI buffer page
         - Show info about WiGig and UWB in debugfs
         - Update information about wireless control"
      
      * tag 'platform-drivers-x86-v4.2-2' of git://git.infradead.org/users/dvhart/linux-platform-drivers-x86:
        intel_pmc_ipc: Add Intel Apollo Lake PMC IPC driver
        tc1100-wmi: Delete an unnecessary check before the function call "kfree"
        dell-laptop: Fix allocating & freeing SMI buffer page
        dell-laptop: Show info about WiGig and UWB in debugfs
        dell-laptop: Update information about wireless control
      a585d2b7
  5. 05 7月, 2015 33 次提交