1. 09 6月, 2017 1 次提交
  2. 28 3月, 2017 1 次提交
    • T
      LSM: Revive security_task_alloc() hook and per "struct task_struct" security blob. · e4e55b47
      Tetsuo Handa 提交于
      We switched from "struct task_struct"->security to "struct cred"->security
      in Linux 2.6.29. But not all LSM modules were happy with that change.
      TOMOYO LSM module is an example which want to use per "struct task_struct"
      security blob, for TOMOYO's security context is defined based on "struct
      task_struct" rather than "struct cred". AppArmor LSM module is another
      example which want to use it, for AppArmor is currently abusing the cred
      a little bit to store the change_hat and setexeccon info. Although
      security_task_free() hook was revived in Linux 3.4 because Yama LSM module
      wanted to release per "struct task_struct" security blob,
      security_task_alloc() hook and "struct task_struct"->security field were
      not revived. Nowadays, we are getting proposals of lightweight LSM modules
      which want to use per "struct task_struct" security blob.
      
      We are already allowing multiple concurrent LSM modules (up to one fully
      armored module which uses "struct cred"->security field or exclusive hooks
      like security_xfrm_state_pol_flow_match(), plus unlimited number of
      lightweight modules which do not use "struct cred"->security nor exclusive
      hooks) as long as they are built into the kernel. But this patch does not
      implement variable length "struct task_struct"->security field which will
      become needed when multiple LSM modules want to use "struct task_struct"->
      security field. Although it won't be difficult to implement variable length
      "struct task_struct"->security field, let's think about it after we merged
      this patch.
      Signed-off-by: NTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      Acked-by: NJohn Johansen <john.johansen@canonical.com>
      Acked-by: NSerge Hallyn <serge@hallyn.com>
      Acked-by: NCasey Schaufler <casey@schaufler-ca.com>
      Tested-by: NDjalal Harouni <tixxdz@gmail.com>
      Acked-by: NJosé Bollo <jobol@nonadev.net>
      Cc: Paul Moore <paul@paul-moore.com>
      Cc: Stephen Smalley <sds@tycho.nsa.gov>
      Cc: Eric Paris <eparis@parisplace.org>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: James Morris <james.l.morris@oracle.com>
      Cc: José Bollo <jobol@nonadev.net>
      Signed-off-by: NJames Morris <james.l.morris@oracle.com>
      e4e55b47
  3. 06 3月, 2017 1 次提交
    • S
      prlimit,security,selinux: add a security hook for prlimit · 791ec491
      Stephen Smalley 提交于
      When SELinux was first added to the kernel, a process could only get
      and set its own resource limits via getrlimit(2) and setrlimit(2), so no
      MAC checks were required for those operations, and thus no security hooks
      were defined for them. Later, SELinux introduced a hook for setlimit(2)
      with a check if the hard limit was being changed in order to be able to
      rely on the hard limit value as a safe reset point upon context
      transitions.
      
      Later on, when prlimit(2) was added to the kernel with the ability to get
      or set resource limits (hard or soft) of another process, LSM/SELinux was
      not updated other than to pass the target process to the setrlimit hook.
      This resulted in incomplete control over both getting and setting the
      resource limits of another process.
      
      Add a new security_task_prlimit() hook to the check_prlimit_permission()
      function to provide complete mediation.  The hook is only called when
      acting on another task, and only if the existing DAC/capability checks
      would allow access.  Pass flags down to the hook to indicate whether the
      prlimit(2) call will read, write, or both read and write the resource
      limits of the target process.
      
      The existing security_task_setrlimit() hook is left alone; it continues
      to serve a purpose in supporting the ability to make decisions based on
      the old and/or new resource limit values when setting limits.  This
      is consistent with the DAC/capability logic, where
      check_prlimit_permission() performs generic DAC/capability checks for
      acting on another task, while do_prlimit() performs a capability check
      based on a comparison of the old and new resource limits.  Fix the
      inline documentation for the hook to match the code.
      
      Implement the new hook for SELinux.  For setting resource limits, we
      reuse the existing setrlimit permission.  Note that this does overload
      the setrlimit permission to mean the ability to set the resource limit
      (soft or hard) of another process or the ability to change one's own
      hard limit.  For getting resource limits, a new getrlimit permission
      is defined.  This was not originally defined since getrlimit(2) could
      only be used to obtain a process' own limits.
      Signed-off-by: NStephen Smalley <sds@tycho.nsa.gov>
      Signed-off-by: NJames Morris <james.l.morris@oracle.com>
      791ec491
  4. 24 1月, 2017 1 次提交
  5. 13 1月, 2017 1 次提交
  6. 09 1月, 2017 1 次提交
  7. 09 8月, 2016 4 次提交
  8. 21 7月, 2016 1 次提交
  9. 23 4月, 2016 1 次提交
    • B
      security: Introduce security_settime64() · 457db29b
      Baolin Wang 提交于
      security_settime() uses a timespec, which is not year 2038 safe
      on 32bit systems. Thus this patch introduces the security_settime64()
      function with timespec64 type. We also convert the cap_settime() helper
      function to use the 64bit types.
      
      This patch then moves security_settime() to the header file as an
      inline helper function so that existing users can be iteratively
      converted.
      
      None of the existing hooks is using the timespec argument and therefor
      the patch is not making any functional changes.
      
      Cc: Serge Hallyn <serge.hallyn@canonical.com>,
      Cc: James Morris <james.l.morris@oracle.com>,
      Cc: "Serge E. Hallyn" <serge@hallyn.com>,
      Cc: Paul Moore <pmoore@redhat.com>
      Cc: Stephen Smalley <sds@tycho.nsa.gov>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Prarit Bhargava <prarit@redhat.com>
      Cc: Richard Cochran <richardcochran@gmail.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@kernel.org>
      Reviewed-by: NJames Morris <james.l.morris@oracle.com>
      Signed-off-by: NBaolin Wang <baolin.wang@linaro.org>
      [jstultz: Reworded commit message]
      Signed-off-by: NJohn Stultz <john.stultz@linaro.org>
      457db29b
  10. 28 3月, 2016 9 次提交
  11. 21 2月, 2016 4 次提交
  12. 19 2月, 2016 2 次提交
  13. 25 12月, 2015 3 次提交
  14. 21 9月, 2015 1 次提交
  15. 12 5月, 2015 3 次提交
  16. 11 5月, 2015 2 次提交
    • N
      security: make inode_follow_link RCU-walk aware · bda0be7a
      NeilBrown 提交于
      inode_follow_link now takes an inode and rcu flag as well as the
      dentry.
      
      inode is used in preference to d_backing_inode(dentry), particularly
      in RCU-walk mode.
      
      selinux_inode_follow_link() gets dentry_has_perm() and
      inode_has_perm() open-coded into it so that it can call
      avc_has_perm_flags() in way that is safe if LOOKUP_RCU is set.
      
      Calling avc_has_perm_flags() with rcu_read_lock() held means
      that when avc_has_perm_noaudit calls avc_compute_av(), the attempt
      to rcu_read_unlock() before calling security_compute_av() will not
      actually drop the RCU read-lock.
      
      However as security_compute_av() is completely in a read_lock()ed
      region, it should be safe with the RCU read-lock held.
      Signed-off-by: NNeilBrown <neilb@suse.de>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      bda0be7a
    • N
      SECURITY: remove nameidata arg from inode_follow_link. · 37882db0
      NeilBrown 提交于
      No ->inode_follow_link() methods use the nameidata arg, and
      it is about to become private to namei.c.
      So remove from all inode_follow_link() functions.
      Signed-off-by: NNeilBrown <neilb@suse.de>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      37882db0
  17. 12 4月, 2015 1 次提交
  18. 21 3月, 2015 1 次提交
  19. 26 1月, 2015 1 次提交
    • S
      Add security hooks to binder and implement the hooks for SELinux. · 79af7307
      Stephen Smalley 提交于
      Add security hooks to the binder and implement the hooks for SELinux.
      The security hooks enable security modules such as SELinux to implement
      controls over binder IPC.  The security hooks include support for
      controlling what process can become the binder context manager
      (binder_set_context_mgr), controlling the ability of a process
      to invoke a binder transaction/IPC to another process (binder_transaction),
      controlling the ability of a process to transfer a binder reference to
      another process (binder_transfer_binder), and controlling the ability
      of a process to transfer an open file to another process (binder_transfer_file).
      
      These hooks have been included in the Android kernel trees since Android 4.3.
      
      (Updated to reflect upstream relocation and changes to the binder driver,
      changes to the LSM audit data structures, coding style cleanups, and
      to add inline documentation for the hooks).
      Signed-off-by: NStephen Smalley <sds@tycho.nsa.gov>
      Acked-by: NNick Kralevich <nnk@google.com>
      Acked-by: NJeffrey Vander Stoep <jeffv@google.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      79af7307
  20. 10 9月, 2014 1 次提交