1. 28 Mar, 2017 1 commit
    • Tetsuo Handa's avatar
      LSM: Revive security_task_alloc() hook and per "struct task_struct" security blob. · e4e55b47
      Tetsuo Handa authored
      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: default avatarTetsuo Handa <[email protected]>
      Acked-by: default avatarJohn Johansen <[email protected]>
      Acked-by: Serge Hallyn's avatarSerge Hallyn <[email protected]>
      Acked-by: default avatarCasey Schaufler <[email protected]>
      Tested-by: Djalal Harouni's avatarDjalal Harouni <[email protected]>
      Acked-by: josé bollo's avatarJosé Bollo <[email protected]>
      Cc: Paul Moore <[email protected]>
      Cc: Stephen Smalley <[email protected]>
      Cc: Eric Paris <[email protected]>
      Cc: Kees Cook <[email protected]>
      Cc: James Morris <[email protected]>
      Cc: José Bollo <[email protected]>
      Signed-off-by: default avatarJames Morris <[email protected]>
      e4e55b47
  2. 24 Mar, 2017 1 commit
  3. 06 Mar, 2017 1 commit
  4. 05 Mar, 2017 1 commit
    • Stephen Smalley's avatar
      prlimit,security,selinux: add a security hook for prlimit · 791ec491
      Stephen Smalley authored
      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: Stephen Smalley's avatarStephen Smalley <[email protected]>
      Signed-off-by: default avatarJames Morris <[email protected]>
      791ec491
  5. 19 Jan, 2017 1 commit
  6. 12 Jan, 2017 1 commit
  7. 09 Jan, 2017 1 commit
  8. 09 Aug, 2016 3 commits
  9. 21 Jul, 2016 1 commit
  10. 06 Jun, 2016 1 commit
    • Casey Schaufler's avatar
      LSM: Fix for security_inode_getsecurity and -EOPNOTSUPP · 2885c1e3
      Casey Schaufler authored
      Serge Hallyn pointed out that the current implementation of
      security_inode_getsecurity() works if there is only one hook
      provided for it, but will fail if there is more than one and
      the attribute requested isn't supplied by the first module.
      This isn't a problem today, since only SELinux and Smack
      provide this hook and there is (currently) no way to enable
      both of those modules at the same time. Serge, however, wants
      to introduce a capability attribute and an inode_getsecurity
      hook in the capability security module to handle it. This
      addresses that upcoming problem, will be required for "extreme
      stacking" and is just a better implementation.
      Signed-off-by: default avatarCasey Schaufler <[email protected]>
      Acked-by: Serge Hallyn's avatarSerge Hallyn <[email protected]>
      Signed-off-by: default avatarJames Morris <[email protected]>
      2885c1e3
  11. 22 Apr, 2016 1 commit
  12. 21 Apr, 2016 1 commit
  13. 11 Apr, 2016 1 commit
  14. 28 Mar, 2016 9 commits
  15. 21 Feb, 2016 4 commits
    • Mimi Zohar's avatar
      module: replace copy_module_from_fd with kernel version · a1db7420
      Mimi Zohar authored
      Replace copy_module_from_fd() with kernel_read_file_from_fd().
      
      Although none of the upstreamed LSMs define a kernel_module_from_file
      hook, IMA is called, based on policy, to prevent unsigned kernel modules
      from being loaded by the original kernel module syscall and to
      measure/appraise signed kernel modules.
      
      The security function security_kernel_module_from_file() was called prior
      to reading a kernel module.  Preventing unsigned kernel modules from being
      loaded by the original kernel module syscall remains on the pre-read
      kernel_read_file() security hook.  Instead of reading the kernel module
      twice, once for measuring/appraising and again for loading the kernel
      module, the signature validation is moved to the kernel_post_read_file()
      security hook.
      
      This patch removes the security_kernel_module_from_file() hook and security
      call.
      Signed-off-by: default avatarMimi Zohar <[email protected]>
      Acked-by: default avatarKees Cook <[email protected]>
      Acked-by: default avatarLuis R. Rodriguez <[email protected]>
      Cc: Rusty Russell <[email protected]>
      a1db7420
    • Mimi Zohar's avatar
      security: define kernel_read_file hook · 39eeb4fb
      Mimi Zohar authored
      The kernel_read_file security hook is called prior to reading the file
      into memory.
      
      Changelog v4+:
      - export security_kernel_read_file()
      Signed-off-by: default avatarMimi Zohar <[email protected]>
      Acked-by: default avatarKees Cook <[email protected]>
      Acked-by: default avatarLuis R. Rodriguez <[email protected]>
      Acked-by: default avatarCasey Schaufler <[email protected]>
      39eeb4fb
    • Mimi Zohar's avatar
      firmware: replace call to fw_read_file_contents() with kernel version · e40ba6d5
      Mimi Zohar authored
      Replace the fw_read_file_contents with kernel_file_read_from_path().
      
      Although none of the upstreamed LSMs define a kernel_fw_from_file hook,
      IMA is called by the security function to prevent unsigned firmware from
      being loaded and to measure/appraise signed firmware, based on policy.
      
      Instead of reading the firmware twice, once for measuring/appraising the
      firmware and again for reading the firmware contents into memory, the
      kernel_post_read_file() security hook calculates the file hash based on
      the in memory file buffer.  The firmware is read once.
      
      This patch removes the LSM kernel_fw_from_file() hook and security call.
      
      Changelog v4+:
      - revert dropped buf->size assignment - reported by Sergey Senozhatsky
      v3:
      - remove kernel_fw_from_file hook
      - use kernel_file_read_from_path() - requested by Luis
      v2:
      - reordered and squashed firmware patches
      - fix MAX firmware size (Kees Cook)
      Signed-off-by: default avatarMimi Zohar <[email protected]>
      Acked-by: default avatarKees Cook <[email protected]>
      Acked-by: default avatarLuis R. Rodriguez <[email protected]>
      e40ba6d5
    • Mimi Zohar's avatar
      ima: define a new hook to measure and appraise a file already in memory · cf222217
      Mimi Zohar authored
      This patch defines a new IMA hook ima_post_read_file() for measuring
      and appraising files read by the kernel. The caller loads the file into
      memory before calling this function, which calculates the hash followed by
      the normal IMA policy based processing.
      
      Changelog v5:
      - fail ima_post_read_file() if either file or buf is NULL
      v3:
      - rename ima_hash_and_process_file() to ima_post_read_file()
      
      v1:
      - split patch
      Signed-off-by: default avatarMimi Zohar <[email protected]>
      Acked-by: default avatarDmitry Kasatkin <[email protected]>
      cf222217
  16. 18 Feb, 2016 2 commits
  17. 24 Dec, 2015 3 commits
  18. 25 Aug, 2015 1 commit
  19. 28 Jul, 2015 1 commit
  20. 10 Jul, 2015 1 commit
    • Eric W. Biederman's avatar
      vfs: Commit to never having exectuables on proc and sysfs. · 90f8572b
      Eric W. Biederman authored
      Today proc and sysfs do not contain any executable files.  Several
      applications today mount proc or sysfs without noexec and nosuid and
      then depend on there being no exectuables files on proc or sysfs.
      Having any executable files show on proc or sysfs would cause
      a user space visible regression, and most likely security problems.
      
      Therefore commit to never allowing executables on proc and sysfs by
      adding a new flag to mark them as filesystems without executables and
      enforce that flag.
      
      Test the flag where MNT_NOEXEC is tested today, so that the only user
      visible effect will be that exectuables will be treated as if the
      execute bit is cleared.
      
      The filesystems proc and sysfs do not currently incoporate any
      executable files so this does not result in any user visible effects.
      
      This makes it unnecessary to vet changes to proc and sysfs tightly for
      adding exectuable files or changes to chattr that would modify
      existing files, as no matter what the individual file say they will
      not be treated as exectuable files by the vfs.
      
      Not having to vet changes to closely is important as without this we
      are only one proc_create call (or another goof up in the
      implementation of notify_change) from having problematic executables
      on proc.  Those mistakes are all too easy to make and would create
      a situation where there are security issues or the assumptions of
      some program having to be broken (and cause userspace regressions).
      Signed-off-by: default avatar"Eric W. Biederman" <[email protected]>
      90f8572b
  21. 12 May, 2015 3 commits
  22. 11 May, 2015 1 commit
    • NeilBrown's avatar
      security: make inode_follow_link RCU-walk aware · bda0be7a
      NeilBrown authored
      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: default avatarNeilBrown <[email protected]>
      Signed-off-by: default avatarAl Viro <[email protected]>
      bda0be7a