1. 12 4月, 2018 1 次提交
    • 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
  2. 28 3月, 2018 1 次提交
  3. 23 3月, 2018 4 次提交
  4. 07 3月, 2018 1 次提交
  5. 01 3月, 2018 1 次提交
  6. 11 1月, 2018 1 次提交
  7. 28 12月, 2017 1 次提交
  8. 02 11月, 2017 1 次提交
  9. 04 10月, 2017 1 次提交
    • C
      lsm: fix smack_inode_removexattr and xattr_getsecurity memleak · 57e7ba04
      Casey Schaufler 提交于
      security_inode_getsecurity() provides the text string value
      of a security attribute. It does not provide a "secctx".
      The code in xattr_getsecurity() that calls security_inode_getsecurity()
      and then calls security_release_secctx() happened to work because
      SElinux and Smack treat the attribute and the secctx the same way.
      It fails for cap_inode_getsecurity(), because that module has no
      secctx that ever needs releasing. It turns out that Smack is the
      one that's doing things wrong by not allocating memory when instructed
      to do so by the "alloc" parameter.
      
      The fix is simple enough. Change the security_release_secctx() to
      kfree() because it isn't a secctx being returned by
      security_inode_getsecurity(). Change Smack to allocate the string when
      told to do so.
      
      Note: this also fixes memory leaks for LSMs which implement
      inode_getsecurity but not release_secctx, such as capabilities.
      Signed-off-by: NCasey Schaufler <casey@schaufler-ca.com>
      Reported-by: NKonstantin Khlebnikov <khlebnikov@yandex-team.ru>
      Cc: stable@vger.kernel.org
      Signed-off-by: NJames Morris <james.l.morris@oracle.com>
      57e7ba04
  10. 02 8月, 2017 3 次提交
  11. 02 6月, 2017 1 次提交
  12. 05 4月, 2017 1 次提交
  13. 06 3月, 2017 1 次提交
  14. 24 1月, 2017 1 次提交
  15. 19 1月, 2017 1 次提交
  16. 13 1月, 2017 1 次提交
  17. 11 1月, 2017 9 次提交
  18. 09 1月, 2017 1 次提交
  19. 05 12月, 2016 1 次提交
  20. 16 11月, 2016 1 次提交
    • C
      Smack: Remove unnecessary smack_known_invalid · 152f91d4
      Casey Schaufler 提交于
      The invalid Smack label ("") and the Huh ("?") Smack label
      serve the same purpose and having both is unnecessary.
      While pulling out the invalid label it became clear that
      the use of smack_from_secid() was inconsistent, so that
      is repaired. The setting of inode labels to the invalid
      label could never happen in a functional system, has
      never been observed in the wild and is not what you'd
      really want for a failure behavior in any case. That is
      removed.
      Signed-off-by: NCasey Schaufler <casey@schaufler-ca.com>
      152f91d4
  21. 15 11月, 2016 1 次提交
  22. 11 11月, 2016 4 次提交
    • C
      Smack: ipv6 label match fix · 2e4939f7
      Casey Schaufler 提交于
      The check for a deleted entry in the list of IPv6 host
      addresses was being performed in the wrong place, leading
      to most peculiar results in some cases. This puts the
      check into the right place.
      Signed-off-by: NCasey Schaufler <casey@schaufler-ca.com>
      2e4939f7
    • H
      SMACK: Fix the memory leak in smack_cred_prepare() hook · b437aba8
      Himanshu Shukla 提交于
      Memory leak in smack_cred_prepare()function.
      smack_cred_prepare() hook returns error if there is error in allocating
      memory in smk_copy_rules() or smk_copy_relabel() function.
      If smack_cred_prepare() function returns error then the calling
      function should call smack_cred_free() function for cleanup.
      In smack_cred_free() function first credential is  extracted and
      then all rules are deleted. In smack_cred_prepare() function security
      field is assigned in the end when all function return success. But this
      function may return before and memory will not be freed.
      Signed-off-by: NHimanshu Shukla <himanshu.sh@samsung.com>
      Acked-by: NCasey Schaufler <casey@schaufler-ca.com>
      b437aba8
    • H
      SMACK: Do not apply star label in smack_setprocattr hook · 7128ea15
      Himanshu Shukla 提交于
      Smack prohibits processes from using the star ("*") and web ("@") labels.
      Checks have been added in other functions. In smack_setprocattr()
      hook, only check for web ("@") label has been added and restricted
      from applying web ("@") label.
      Check for star ("*") label should also be added in smack_setprocattr()
      hook. Return error should be "-EINVAL" not "-EPERM" as permission
      is there for setting label but not the label value as star ("*") or
      web ("@").
      Signed-off-by: NHimanshu Shukla <himanshu.sh@samsung.com>
      Acked-by: NCasey Schaufler <casey@schaufler-ca.com>
      7128ea15
    • H
      smack: parse mnt opts after privileges check · 2097f599
      Himanshu Shukla 提交于
      In smack_set_mnt_opts()first the SMACK mount options are being
      parsed and later it is being checked whether the user calling
      mount has CAP_MAC_ADMIN capability.
      This sequence of operationis will allow unauthorized user to add
      SMACK labels in label list and may cause denial of security attack
      by adding many labels by allocating kernel memory by unauthorized user.
      Superblock smack flag is also being set as initialized though function
      may return with EPERM error.
      First check the capability of calling user then set the SMACK attributes
      and smk_flags.
      Signed-off-by: NHimanshu Shukla <himanshu.sh@samsung.com>
      Acked-by: NCasey Schaufler <casey@schaufler-ca.com>
      2097f599
  23. 05 11月, 2016 1 次提交
  24. 08 10月, 2016 1 次提交