1. 07 3月, 2018 1 次提交
  2. 11 1月, 2018 1 次提交
  3. 28 12月, 2017 1 次提交
  4. 02 11月, 2017 1 次提交
  5. 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
  6. 02 8月, 2017 3 次提交
  7. 02 6月, 2017 1 次提交
  8. 05 4月, 2017 1 次提交
  9. 06 3月, 2017 1 次提交
  10. 24 1月, 2017 1 次提交
  11. 19 1月, 2017 1 次提交
  12. 13 1月, 2017 1 次提交
  13. 11 1月, 2017 9 次提交
  14. 09 1月, 2017 1 次提交
  15. 05 12月, 2016 1 次提交
  16. 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
  17. 15 11月, 2016 1 次提交
  18. 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
  19. 05 11月, 2016 1 次提交
  20. 08 10月, 2016 1 次提交
  21. 09 9月, 2016 1 次提交
    • C
      Smack: Signal delivery as an append operation · c60b9066
      Casey Schaufler 提交于
      Under a strict subject/object security policy delivering a
      signal or delivering network IPC could be considered either
      a write or an append operation. The original choice to make
      both write operations leads to an issue where IPC delivery
      is desired under policy, but delivery of signals is not.
      This patch provides the option of making signal delivery
      an append operation, allowing Smack rules that deny signal
      delivery while allowing IPC. This was requested for Tizen.
      Signed-off-by: NCasey Schaufler <casey@schaufler-ca.com>
      c60b9066
  22. 28 6月, 2016 1 次提交
  23. 25 6月, 2016 1 次提交
  24. 24 6月, 2016 1 次提交
    • S
      Smack: Add support for unprivileged mounts from user namespaces · 9f50eda2
      Seth Forshee 提交于
      Security labels from unprivileged mounts cannot be trusted.
      Ideally for these mounts we would assign the objects in the
      filesystem the same label as the inode for the backing device
      passed to mount. Unfortunately it's currently impossible to
      determine which inode this is from the LSM mount hooks, so we
      settle for the label of the process doing the mount.
      
      This label is assigned to s_root, and also to smk_default to
      ensure that new inodes receive this label. The transmute property
      is also set on s_root to make this behavior more explicit, even
      though it is technically not necessary.
      
      If a filesystem has existing security labels, access to inodes is
      permitted if the label is the same as smk_root, otherwise access
      is denied. The SMACK64EXEC xattr is completely ignored.
      
      Explicit setting of security labels continues to require
      CAP_MAC_ADMIN in init_user_ns.
      
      Altogether, this ensures that filesystem objects are not
      accessible to subjects which cannot already access the backing
      store, that MAC is not violated for any objects in the fileystem
      which are already labeled, and that a user cannot use an
      unprivileged mount to gain elevated MAC privileges.
      
      sysfs, tmpfs, and ramfs are already mountable from user
      namespaces and support security labels. We can't rule out the
      possibility that these filesystems may already be used in mounts
      from user namespaces with security lables set from the init
      namespace, so failing to trust lables in these filesystems may
      introduce regressions. It is safe to trust labels from these
      filesystems, since the unprivileged user does not control the
      backing store and thus cannot supply security labels, so an
      explicit exception is made to trust labels from these
      filesystems.
      Signed-off-by: NSeth Forshee <seth.forshee@canonical.com>
      Acked-by: NCasey Schaufler <casey@schaufler-ca.com>
      Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
      9f50eda2
  25. 09 6月, 2016 1 次提交
    • R
      Smack: ignore null signal in smack_task_kill · 18d872f7
      Rafal Krypa 提交于
      Kill with signal number 0 is commonly used for checking PID existence.
      Smack treated such cases like any other kills, although no signal is
      actually delivered when sig == 0.
      
      Checking permissions when sig == 0 didn't prevent an unprivileged caller
      from learning whether PID exists or not. When it existed, kernel returned
      EPERM, when it didn't - ESRCH. The only effect of policy check in such
      case is noise in audit logs.
      
      This change lets Smack silently ignore kill() invocations with sig == 0.
      Signed-off-by: NRafal Krypa <r.krypa@samsung.com>
      Acked-by: NCasey Schaufler <casey@schaufler-ca.com>
      18d872f7
  26. 28 5月, 2016 1 次提交
  27. 11 4月, 2016 1 次提交