1. 28 2月, 2019 2 次提交
  2. 23 2月, 2019 1 次提交
    • G
      security: mark expected switch fall-throughs and add a missing break · 09186e50
      Gustavo A. R. Silva 提交于
      In preparation to enabling -Wimplicit-fallthrough, mark switch
      cases where we are expecting to fall through.
      
      This patch fixes the following warnings:
      
      security/integrity/ima/ima_template_lib.c:85:10: warning: this statement may fall through [-Wimplicit-fallthrough=]
      security/integrity/ima/ima_policy.c:940:18: warning: this statement may fall through [-Wimplicit-fallthrough=]
      security/integrity/ima/ima_policy.c:943:7: warning: this statement may fall through [-Wimplicit-fallthrough=]
      security/integrity/ima/ima_policy.c:972:21: warning: this statement may fall through [-Wimplicit-fallthrough=]
      security/integrity/ima/ima_policy.c:974:7: warning: this statement may fall through [-Wimplicit-fallthrough=]
      security/smack/smack_lsm.c:3391:9: warning: this statement may fall through [-Wimplicit-fallthrough=]
      security/apparmor/domain.c:569:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
      
      Warning level 3 was used: -Wimplicit-fallthrough=3
      
      Also, add a missing break statement to fix the following warning:
      
      security/integrity/ima/ima_appraise.c:116:26: warning: this statement may fall through [-Wimplicit-fallthrough=]
      Acked-by: NJohn Johansen <john.johansen@canonical.com>
      Acked-by: NCasey Schaufler <casey@schaufler-ca.com>
      Signed-off-by: NGustavo A. R. Silva <gustavo@embeddedor.com>
      Acked-by: NMimi Zohar <zohar@linux.ibm.com>
      Signed-off-by: NJames Morris <james.morris@microsoft.com>
      09186e50
  3. 01 2月, 2019 1 次提交
  4. 19 1月, 2019 1 次提交
  5. 09 1月, 2019 11 次提交
  6. 22 12月, 2018 10 次提交
  7. 04 12月, 2018 1 次提交
    • Z
      smack: fix access permissions for keyring · 5b841bfa
      Zoran Markovic 提交于
      Function smack_key_permission() only issues smack requests for the
      following operations:
       - KEY_NEED_READ (issues MAY_READ)
       - KEY_NEED_WRITE (issues MAY_WRITE)
       - KEY_NEED_LINK (issues MAY_WRITE)
       - KEY_NEED_SETATTR (issues MAY_WRITE)
      A blank smack request is issued in all other cases, resulting in
      smack access being granted if there is any rule defined between
      subject and object, or denied with -EACCES otherwise.
      
      Request MAY_READ access for KEY_NEED_SEARCH and KEY_NEED_VIEW.
      Fix the logic in the unlikely case when both MAY_READ and
      MAY_WRITE are needed. Validate access permission field for valid
      contents.
      Signed-off-by: NZoran Markovic <zmarkovic@sierrawireless.com>
      Signed-off-by: NCasey Schaufler <casey@schaufler-ca.com>
      Cc: Casey Schaufler <casey@schaufler-ca.com>
      Cc: James Morris <jmorris@namei.org>
      Cc: "Serge E. Hallyn" <serge@hallyn.com>
      5b841bfa
  8. 11 10月, 2018 2 次提交
  9. 03 10月, 2018 1 次提交
    • E
      signal: Distinguish between kernel_siginfo and siginfo · ae7795bc
      Eric W. Biederman 提交于
      Linus recently observed that if we did not worry about the padding
      member in struct siginfo it is only about 48 bytes, and 48 bytes is
      much nicer than 128 bytes for allocating on the stack and copying
      around in the kernel.
      
      The obvious thing of only adding the padding when userspace is
      including siginfo.h won't work as there are sigframe definitions in
      the kernel that embed struct siginfo.
      
      So split siginfo in two; kernel_siginfo and siginfo.  Keeping the
      traditional name for the userspace definition.  While the version that
      is used internally to the kernel and ultimately will not be padded to
      128 bytes is called kernel_siginfo.
      
      The definition of struct kernel_siginfo I have put in include/signal_types.h
      
      A set of buildtime checks has been added to verify the two structures have
      the same field offsets.
      
      To make it easy to verify the change kernel_siginfo retains the same
      size as siginfo.  The reduction in size comes in a following change.
      Signed-off-by: N"Eric W. Biederman" <ebiederm@xmission.com>
      ae7795bc
  10. 19 9月, 2018 2 次提交
  11. 24 7月, 2018 3 次提交
  12. 12 7月, 2018 1 次提交
  13. 23 6月, 2018 1 次提交
  14. 06 6月, 2018 1 次提交
  15. 05 5月, 2018 1 次提交
  16. 12 4月, 2018 1 次提交
    • D
      ipc/msg: introduce msgctl(MSG_STAT_ANY) · 23c8cec8
      Davidlohr Bueso 提交于
      There is a permission discrepancy when consulting msq ipc object
      metadata between /proc/sysvipc/msg (0444) and the MSG_STAT shmctl
      command.  The later does permission checks for the object vs S_IRUGO.
      As such there can be cases where EACCESS is returned via syscall but the
      info is displayed anyways in the procfs files.
      
      While this might have security implications via info leaking (albeit no
      writing to the msq metadata), this behavior goes way back and showing
      all the objects regardless of the permissions was most likely an
      overlook - so we are stuck with it.  Furthermore, modifying either the
      syscall or the procfs file can cause userspace programs to break (ie
      ipcs).  Some applications require getting the procfs info (without root
      privileges) and can be rather slow in comparison with a syscall -- up to
      500x in some reported cases for shm.
      
      This patch introduces a new MSG_STAT_ANY command such that the msq ipc
      object permissions are ignored, and only audited instead.  In addition,
      I've left the lsm security hook checks in place, as if some policy can
      block the call, then the user has no other choice than just parsing the
      procfs file.
      
      Link: http://lkml.kernel.org/r/20180215162458.10059-4-dave@stgolabs.netSigned-off-by: NDavidlohr Bueso <dbueso@suse.de>
      Reported-by: NRobert Kettler <robert.kettler@outlook.com>
      Cc: Eric W. Biederman <ebiederm@xmission.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Manfred Spraul <manfred@colorfullife.com>
      Cc: Michael Kerrisk <mtk.manpages@gmail.com>
      Cc: Michal Hocko <mhocko@kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      23c8cec8