1. 14 11月, 2018 1 次提交
  2. 17 7月, 2018 1 次提交
  3. 12 7月, 2018 1 次提交
  4. 20 6月, 2018 1 次提交
  5. 16 6月, 2018 1 次提交
  6. 15 5月, 2018 4 次提交
  7. 14 5月, 2018 2 次提交
  8. 05 5月, 2018 1 次提交
  9. 04 5月, 2018 1 次提交
  10. 12 4月, 2018 3 次提交
    • 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
    • D
      ipc/sem: introduce semctl(SEM_STAT_ANY) · a280d6dc
      Davidlohr Bueso 提交于
      There is a permission discrepancy when consulting shm ipc object
      metadata between /proc/sysvipc/sem (0444) and the SEM_STAT semctl
      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 sma 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 SEM_STAT_ANY command such that the sem 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-3-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>
      a280d6dc
    • D
      ipc/shm: introduce shmctl(SHM_STAT_ANY) · c21a6970
      Davidlohr Bueso 提交于
      Patch series "sysvipc: introduce STAT_ANY commands", v2.
      
      The following patches adds the discussed (see [1]) new command for shm
      as well as for sems and msq as they are subject to the same
      discrepancies for ipc object permission checks between the syscall and
      via procfs.  These new commands are justified in that (1) we are stuck
      with this semantics as changing syscall and procfs can break userland;
      and (2) some users can benefit from performance (for large amounts of
      shm segments, for example) from not having to parse the procfs
      interface.
      
      Once merged, I will submit the necesary manpage updates.  But I'm thinking
      something like:
      
      : diff --git a/man2/shmctl.2 b/man2/shmctl.2
      : index 7bb503999941..bb00bbe21a57 100644
      : --- a/man2/shmctl.2
      : +++ b/man2/shmctl.2
      : @@ -41,6 +41,7 @@
      :  .\" 2005-04-25, mtk -- noted aberrant Linux behavior w.r.t. new
      :  .\"	attaches to a segment that has already been marked for deletion.
      :  .\" 2005-08-02, mtk: Added IPC_INFO, SHM_INFO, SHM_STAT descriptions.
      : +.\" 2018-02-13, dbueso: Added SHM_STAT_ANY description.
      :  .\"
      :  .TH SHMCTL 2 2017-09-15 "Linux" "Linux Programmer's Manual"
      :  .SH NAME
      : @@ -242,6 +243,18 @@ However, the
      :  argument is not a segment identifier, but instead an index into
      :  the kernel's internal array that maintains information about
      :  all shared memory segments on the system.
      : +.TP
      : +.BR SHM_STAT_ANY " (Linux-specific)"
      : +Return a
      : +.I shmid_ds
      : +structure as for
      : +.BR SHM_STAT .
      : +However, the
      : +.I shm_perm.mode
      : +is not checked for read access for
      : +.IR shmid ,
      : +resembing the behaviour of
      : +/proc/sysvipc/shm.
      :  .PP
      :  The caller can prevent or allow swapping of a shared
      :  memory segment with the following \fIcmd\fP values:
      : @@ -287,7 +300,7 @@ operation returns the index of the highest used entry in the
      :  kernel's internal array recording information about all
      :  shared memory segments.
      :  (This information can be used with repeated
      : -.B SHM_STAT
      : +.B SHM_STAT/SHM_STAT_ANY
      :  operations to obtain information about all shared memory segments
      :  on the system.)
      :  A successful
      : @@ -328,7 +341,7 @@ isn't accessible.
      :  \fIshmid\fP is not a valid identifier, or \fIcmd\fP
      :  is not a valid command.
      :  Or: for a
      : -.B SHM_STAT
      : +.B SHM_STAT/SHM_STAT_ANY
      :  operation, the index value specified in
      :  .I shmid
      :  referred to an array slot that is currently unused.
      
      This patch (of 3):
      
      There is a permission discrepancy when consulting shm ipc object metadata
      between /proc/sysvipc/shm (0444) and the SHM_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 shm 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.
      
      This patch introduces a new SHM_STAT_ANY command such that the shm 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.
      
      [1] https://lkml.org/lkml/2017/12/19/220
      
      Link: http://lkml.kernel.org/r/20180215162458.10059-2-dave@stgolabs.netSigned-off-by: NDavidlohr Bueso <dbueso@suse.de>
      Acked-by: NMichal Hocko <mhocko@suse.com>
      Cc: Michael Kerrisk <mtk.manpages@gmail.com>
      Cc: Manfred Spraul <manfred@colorfullife.com>
      Cc: Eric W. Biederman <ebiederm@xmission.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Robert Kettler <robert.kettler@outlook.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      c21a6970
  11. 28 3月, 2018 1 次提交
  12. 23 3月, 2018 4 次提交
  13. 21 3月, 2018 1 次提交
  14. 07 3月, 2018 1 次提交
  15. 03 3月, 2018 2 次提交
  16. 02 3月, 2018 1 次提交
    • S
      selinux: wrap global selinux state · aa8e712c
      Stephen Smalley 提交于
      Define a selinux state structure (struct selinux_state) for
      global SELinux state and pass it explicitly to all security server
      functions.  The public portion of the structure contains state
      that is used throughout the SELinux code, such as the enforcing mode.
      The structure also contains a pointer to a selinux_ss structure whose
      definition is private to the security server and contains security
      server specific state such as the policy database and SID table.
      
      This change should have no effect on SELinux behavior or APIs
      (userspace or LSM).  It merely wraps SELinux state and passes it
      explicitly as needed.
      Signed-off-by: NStephen Smalley <sds@tycho.nsa.gov>
      [PM: minor fixups needed due to collisions with the SCTP patches]
      Signed-off-by: NPaul Moore <paul@paul-moore.com>
      aa8e712c
  17. 28 2月, 2018 1 次提交
  18. 27 2月, 2018 1 次提交
  19. 20 10月, 2017 2 次提交
  20. 17 10月, 2017 1 次提交
  21. 05 10月, 2017 2 次提交
  22. 04 10月, 2017 1 次提交
    • E
      selinux: Perform both commoncap and selinux xattr checks · 6b240306
      Eric W. Biederman 提交于
      When selinux is loaded the relax permission checks for writing
      security.capable are not honored.  Which keeps file capabilities
      from being used in user namespaces.
      
      Stephen Smalley <sds@tycho.nsa.gov> writes:
      > Originally SELinux called the cap functions directly since there was no
      > stacking support in the infrastructure and one had to manually stack a
      > secondary module internally.  inode_setxattr and inode_removexattr
      > however were special cases because the cap functions would check
      > CAP_SYS_ADMIN for any non-capability attributes in the security.*
      > namespace, and we don't want to impose that requirement on setting
      > security.selinux.  Thus, we inlined the capabilities logic into the
      > selinux hook functions and adapted it appropriately.
      
      Now that the permission checks in commoncap have evolved this
      inlining of their contents has become a problem.  So restructure
      selinux_inode_removexattr, and selinux_inode_setxattr to call
      both the corresponding cap_inode_ function and dentry_has_perm
      when the attribute is not a selinux security xattr.   This ensures
      the policies of both commoncap and selinux are enforced.
      
      This results in smack and selinux having the same basic structure
      for setxattr and removexattr.  Performing their own special permission
      checks when it is their modules xattr being written to, and deferring
      to commoncap when that is not the case.  Then finally performing their
      generic module policy on all xattr writes.
      
      This structure is fine when you only consider stacking with the
      commoncap lsm, but it becomes a problem if two lsms that don't want
      the commoncap security checks on their own attributes need to be
      stack.  This means there will need to be updates in the future as lsm
      stacking is improved, but at least now the structure between smack and
      selinux is common making the code easier to refactor.
      
      This change also has the effect that selinux_linux_setotherxattr becomes
      unnecessary so it is removed.
      
      Fixes: 8db6c34f ("Introduce v3 namespaced file capabilities")
      Fixes: 7bbf0e052b76 ("[PATCH] selinux merge")
      Historical Tree: https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.gitSigned-off-by: N"Eric W. Biederman" <ebiederm@xmission.com>
      Reviewed-by: NSerge Hallyn <serge@hallyn.com>
      Acked-by: NStephen Smalley <sds@tycho.nsa.gov>
      Signed-off-by: NPaul Moore <paul@paul-moore.com>
      6b240306
  23. 29 8月, 2017 1 次提交
  24. 23 8月, 2017 1 次提交
  25. 18 8月, 2017 1 次提交
  26. 03 8月, 2017 1 次提交
    • S
      selinux: Generalize support for NNP/nosuid SELinux domain transitions · af63f419
      Stephen Smalley 提交于
      As systemd ramps up enabling NNP (NoNewPrivileges) for system services,
      it is increasingly breaking SELinux domain transitions for those services
      and their descendants.  systemd enables NNP not only for services whose
      unit files explicitly specify NoNewPrivileges=yes but also for services
      whose unit files specify any of the following options in combination with
      running without CAP_SYS_ADMIN (e.g. specifying User= or a
      CapabilityBoundingSet= without CAP_SYS_ADMIN): SystemCallFilter=,
      SystemCallArchitectures=, RestrictAddressFamilies=, RestrictNamespaces=,
      PrivateDevices=, ProtectKernelTunables=, ProtectKernelModules=,
      MemoryDenyWriteExecute=, or RestrictRealtime= as per the systemd.exec(5)
      man page.
      
      The end result is bad for the security of both SELinux-disabled and
      SELinux-enabled systems.  Packagers have to turn off these
      options in the unit files to preserve SELinux domain transitions.  For
      users who choose to disable SELinux, this means that they miss out on
      at least having the systemd-supported protections.  For users who keep
      SELinux enabled, they may still be missing out on some protections
      because it isn't necessarily guaranteed that the SELinux policy for
      that service provides the same protections in all cases.
      
      commit 7b0d0b40 ("selinux: Permit bounded transitions under
      NO_NEW_PRIVS or NOSUID.") allowed bounded transitions under NNP in
      order to support limited usage for sandboxing programs.  However,
      defining typebounds for all of the affected service domains
      is impractical to implement in policy, since typebounds requires us
      to ensure that each domain is allowed everything all of its descendant
      domains are allowed, and this has to be repeated for the entire chain
      of domain transitions.  There is no way to clone all allow rules from
      descendants to their ancestors in policy currently, and doing so would
      be undesirable even if it were practical, as it requires leaking
      permissions to objects and operations into ancestor domains that could
      weaken their own security in order to allow them to the descendants
      (e.g. if a descendant requires execmem permission, then so do all of
      its ancestors; if a descendant requires execute permission to a file,
      then so do all of its ancestors; if a descendant requires read to a
      symbolic link or temporary file, then so do all of its ancestors...).
      SELinux domains are intentionally not hierarchical / bounded in this
      manner normally, and making them so would undermine their protections
      and least privilege.
      
      We have long had a similar tension with SELinux transitions and nosuid
      mounts, albeit not as severe.  Users often have had to choose between
      retaining nosuid on a mount and allowing SELinux domain transitions on
      files within those mounts.  This likewise leads to unfortunate tradeoffs
      in security.
      
      Decouple NNP/nosuid from SELinux transitions, so that we don't have to
      make a choice between them. Introduce a nnp_nosuid_transition policy
      capability that enables transitions under NNP/nosuid to be based on
      a permission (nnp_transition for NNP; nosuid_transition for nosuid)
      between the old and new contexts in addition to the current support
      for bounded transitions.  Domain transitions can then be allowed in
      policy without requiring the parent to be a strict superset of all of
      its children.
      
      With this change, systemd unit files can be left unmodified from upstream.
      SELinux-disabled and SELinux-enabled users will benefit from retaining any
      of the systemd-provided protections.  SELinux policy will only need to
      be adapted to enable the new policy capability and to allow the
      new permissions between domain pairs as appropriate.
      
      NB: Allowing nnp_transition between two contexts opens up the potential
      for the old context to subvert the new context by installing seccomp
      filters before the execve.  Allowing nosuid_transition between two contexts
      opens up the potential for a context transition to occur on a file from
      an untrusted filesystem (e.g. removable media or remote filesystem).  Use
      with care.
      Signed-off-by: NStephen Smalley <sds@tycho.nsa.gov>
      Signed-off-by: NPaul Moore <paul@paul-moore.com>
      af63f419
  27. 02 8月, 2017 2 次提交