1. 20 2月, 2017 1 次提交
  2. 16 2月, 2017 1 次提交
  3. 15 2月, 2017 3 次提交
  4. 10 2月, 2017 4 次提交
  5. 08 2月, 2017 3 次提交
    • J
    • A
      selinux: allow changing labels for cgroupfs · 1ea0ce40
      Antonio Murdaca 提交于
      This patch allows changing labels for cgroup mounts. Previously, running
      chcon on cgroupfs would throw an "Operation not supported". This patch
      specifically whitelist cgroupfs.
      
      The patch could also allow containers to write only to the systemd cgroup
      for instance, while the other cgroups are kept with cgroup_t label.
      Signed-off-by: NAntonio Murdaca <runcom@redhat.com>
      Acked-by: NStephen Smalley <sds@tycho.nsa.gov>
      Signed-off-by: NPaul Moore <paul@paul-moore.com>
      1ea0ce40
    • S
      selinux: fix off-by-one in setprocattr · a050a570
      Stephen Smalley 提交于
      SELinux tries to support setting/clearing of /proc/pid/attr attributes
      from the shell by ignoring terminating newlines and treating an
      attribute value that begins with a NUL or newline as an attempt to
      clear the attribute.  However, the test for clearing attributes has
      always been wrong; it has an off-by-one error, and this could further
      lead to reading past the end of the allocated buffer since commit
      bb646cdb ("proc_pid_attr_write():
      switch to memdup_user()").  Fix the off-by-one error.
      
      Even with this fix, setting and clearing /proc/pid/attr attributes
      from the shell is not straightforward since the interface does not
      support multiple write() calls (so shells that write the value and
      newline separately will set and then immediately clear the attribute,
      requiring use of echo -n to set the attribute), whereas trying to use
      echo -n "" to clear the attribute causes the shell to skip the
      write() call altogether since POSIX says that a zero-length write
      causes no side effects. Thus, one must use echo -n to set and echo
      without -n to clear, as in the following example:
      $ echo -n unconfined_u:object_r:user_home_t:s0 > /proc/$$/attr/fscreate
      $ cat /proc/$$/attr/fscreate
      unconfined_u:object_r:user_home_t:s0
      $ echo "" > /proc/$$/attr/fscreate
      $ cat /proc/$$/attr/fscreate
      
      Note the use of /proc/$$ rather than /proc/self, as otherwise
      the cat command will read its own attribute value, not that of the shell.
      
      There are no users of this facility to my knowledge; possibly we
      should just get rid of it.
      
      UPDATE: Upon further investigation it appears that a local process
      with the process:setfscreate permission can cause a kernel panic as a
      result of this bug.  This patch fixes CVE-2017-2618.
      Signed-off-by: NStephen Smalley <sds@tycho.nsa.gov>
      [PM: added the update about CVE-2017-2618 to the commit description]
      Cc: stable@vger.kernel.org # 3.5: d6ea83ecSigned-off-by: NPaul Moore <paul@paul-moore.com>
      a050a570
  6. 04 2月, 2017 10 次提交
  7. 28 1月, 2017 2 次提交
  8. 27 1月, 2017 1 次提交
  9. 24 1月, 2017 10 次提交
  10. 23 1月, 2017 1 次提交
    • M
      seccomp: dump core when using SECCOMP_RET_KILL · b25e6716
      Mike Frysinger 提交于
      The SECCOMP_RET_KILL mode is documented as immediately killing the
      process as if a SIGSYS had been sent and not caught (similar to a
      SIGKILL).  However, a SIGSYS is documented as triggering a coredump
      which does not happen today.
      
      This has the advantage of being able to more easily debug a process
      that fails a seccomp filter.  Today, most apps need to recompile and
      change their filter in order to get detailed info out, or manually run
      things through strace, or enable detailed kernel auditing.  Now we get
      coredumps that fit into existing system-wide crash reporting setups.
      
      From a security pov, this shouldn't be a problem.  Unhandled signals
      can already be sent externally which trigger a coredump independent of
      the status of the seccomp filter.  The act of dumping core itself does
      not cause change in execution of the program.
      
      URL: https://crbug.com/676357Signed-off-by: NMike Frysinger <vapier@chromium.org>
      Acked-by: NJorge Lucangeli Obes <jorgelo@chromium.org>
      Acked-by: NKees Cook <keescook@chromium.org>
      Signed-off-by: NJames Morris <james.l.morris@oracle.com>
      b25e6716
  11. 19 1月, 2017 1 次提交
  12. 17 1月, 2017 1 次提交
  13. 16 1月, 2017 2 次提交
新手
引导
客服 返回
顶部