Skip to content
Snippets Groups Projects
  1. Aug 15, 2021
    • Daniel Borkmann's avatar
      bpf: Add lockdown check for probe_write_user helper · d8c38598
      Daniel Borkmann authored
      
      commit 51e1bb9e upstream.
      
      Back then, commit 96ae5227 ("bpf: Add bpf_probe_write_user BPF helper
      to be called in tracers") added the bpf_probe_write_user() helper in order
      to allow to override user space memory. Its original goal was to have a
      facility to "debug, divert, and manipulate execution of semi-cooperative
      processes" under CAP_SYS_ADMIN. Write to kernel was explicitly disallowed
      since it would otherwise tamper with its integrity.
      
      One use case was shown in cf9b1199 ("samples/bpf: Add test/example of
      using bpf_probe_write_user bpf helper") where the program DNATs traffic
      at the time of connect(2) syscall, meaning, it rewrites the arguments to
      a syscall while they're still in userspace, and before the syscall has a
      chance to copy the argument into kernel space. These days we have better
      mechanisms in BPF for achieving the same (e.g. for load-balancers), but
      without having to write to userspace memory.
      
      Of course the bpf_probe_write_user() helper can also be used to abuse
      many other things for both good or bad purpose. Outside of BPF, there is
      a similar mechanism for ptrace(2) such as PTRACE_PEEK{TEXT,DATA} and
      PTRACE_POKE{TEXT,DATA}, but would likely require some more effort.
      Commit 96ae5227 explicitly dedicated the helper for experimentation
      purpose only. Thus, move the helper's availability behind a newly added
      LOCKDOWN_BPF_WRITE_USER lockdown knob so that the helper is disabled under
      the "integrity" mode. More fine-grained control can be implemented also
      from LSM side with this change.
      
      Fixes: 96ae5227 ("bpf: Add bpf_probe_write_user BPF helper to be called in tracers")
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: default avatarAndrii Nakryiko <andrii@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d8c38598
  2. Oct 05, 2020
  3. Jun 23, 2020
    • KP Singh's avatar
      security: Fix hook iteration and default value for inode_copy_up_xattr · 23e390cd
      KP Singh authored
      
      inode_copy_up_xattr returns 0 to indicate the acceptance of the xattr
      and 1 to reject it. If the LSM does not know about the xattr, it's
      expected to return -EOPNOTSUPP, which is the correct default value for
      this hook. BPF LSM, currently, uses 0 as the default value and thereby
      falsely allows all overlay fs xattributes to be copied up.
      
      The iteration logic is also updated from the "bail-on-fail"
      call_int_hook to continue on the non-decisive -EOPNOTSUPP and bail out
      on other values.
      
      Fixes: 98e828a0 ("security: Refactor declaration of LSM hooks")
      Signed-off-by: default avatarKP Singh <kpsingh@google.com>
      Signed-off-by: default avatarJames Morris <jmorris@namei.org>
      23e390cd
  4. Jun 14, 2020
  5. Jun 03, 2020
  6. May 30, 2020
    • Eric W. Biederman's avatar
      exec: Compute file based creds only once · 56305aa9
      Eric W. Biederman authored
      
      Move the computation of creds from prepare_binfmt into begin_new_exec
      so that the creds need only be computed once.  This is just code
      reorganization no semantic changes of any kind are made.
      
      Moving the computation is safe.  I have looked through the kernel and
      verified none of the binfmts look at bprm->cred directly, and that
      there are no helpers that look at bprm->cred indirectly.  Which means
      that it is not a problem to compute the bprm->cred later in the
      execution flow as it is not used until it becomes current->cred.
      
      A new function bprm_creds_from_file is added to contain the work that
      needs to be done.  bprm_creds_from_file first computes which file
      bprm->executable or most likely bprm->file that the bprm->creds
      will be computed from.
      
      The funciton bprm_fill_uid is updated to receive the file instead of
      accessing bprm->file.  The now unnecessary work needed to reset the
      bprm->cred->euid, and bprm->cred->egid is removed from brpm_fill_uid.
      A small comment to document that bprm_fill_uid now only deals with the
      work to handle suid and sgid files.  The default case is already
      heandled by prepare_exec_creds.
      
      The function security_bprm_repopulate_creds is renamed
      security_bprm_creds_from_file and now is explicitly passed the file
      from which to compute the creds.  The documentation of the
      bprm_creds_from_file security hook is updated to explain when the hook
      is called and what it needs to do.  The file is passed from
      cap_bprm_creds_from_file into get_file_caps so that the caps are
      computed for the appropriate file.  The now unnecessary work in
      cap_bprm_creds_from_file to reset the ambient capabilites has been
      removed.  A small comment to document that the work of
      cap_bprm_creds_from_file is to read capabilities from the files
      secureity attribute and derive capabilities from the fact the
      user had uid 0 has been added.
      
      Reviewed-by: default avatarKees Cook <keescook@chromium.org>
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      56305aa9
  7. May 22, 2020
  8. May 21, 2020
  9. May 20, 2020
    • Eric W. Biederman's avatar
      exec: Factor security_bprm_creds_for_exec out of security_bprm_set_creds · b8bff599
      Eric W. Biederman authored
      Today security_bprm_set_creds has several implementations:
      apparmor_bprm_set_creds, cap_bprm_set_creds, selinux_bprm_set_creds,
      smack_bprm_set_creds, and tomoyo_bprm_set_creds.
      
      Except for cap_bprm_set_creds they all test bprm->called_set_creds and
      return immediately if it is true.  The function cap_bprm_set_creds
      ignores bprm->calld_sed_creds entirely.
      
      Create a new LSM hook security_bprm_creds_for_exec that is called just
      before prepare_binprm in __do_execve_file, resulting in a LSM hook
      that is called exactly once for the entire of exec.  Modify the bits
      of security_bprm_set_creds that only want to be called once per exec
      into security_bprm_creds_for_exec, leaving only cap_bprm_set_creds
      behind.
      
      Remove bprm->called_set_creds all of it's former users have been moved
      to security_bprm_creds_for_exec.
      
      Add or upate comments a appropriate to bring them up to date and
      to reflect this change.
      
      Link: https://lkml.kernel.org/r/87v9kszrzh.fsf_-_@x220.int.ebiederm.org
      
      
      Acked-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Acked-by: Casey Schaufler <casey@schaufler-ca.com> # For the LSM and Smack bits
      Reviewed-by: default avatarKees Cook <keescook@chromium.org>
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      b8bff599
  10. May 19, 2020
    • David Howells's avatar
      keys: Make the KEY_NEED_* perms an enum rather than a mask · 8c0637e9
      David Howells authored
      
      Since the meaning of combining the KEY_NEED_* constants is undefined, make
      it so that you can't do that by turning them into an enum.
      
      The enum is also given some extra values to represent special
      circumstances, such as:
      
       (1) The '0' value is reserved and causes a warning to trap the parameter
           being unset.
      
       (2) The key is to be unlinked and we require no permissions on it, only
           the keyring, (this replaces the KEY_LOOKUP_FOR_UNLINK flag).
      
       (3) An override due to CAP_SYS_ADMIN.
      
       (4) An override due to an instantiation token being present.
      
       (5) The permissions check is being deferred to later key_permission()
           calls.
      
      The extra values give the opportunity for LSMs to audit these situations.
      
      [Note: This really needs overhauling so that lookup_user_key() tells
       key_task_permission() and the LSM what operation is being done and leaves
       it to those functions to decide how to map that onto the available
       permits.  However, I don't really want to make these change in the middle
       of the notifications patchset.]
      
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      cc: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
      cc: Paul Moore <paul@paul-moore.com>
      cc: Stephen Smalley <stephen.smalley.work@gmail.com>
      cc: Casey Schaufler <casey@schaufler-ca.com>
      cc: keyrings@vger.kernel.org
      cc: selinux@vger.kernel.org
      8c0637e9
    • David Howells's avatar
      security: Add hooks to rule on setting a watch · 998f5040
      David Howells authored
      
      Add security hooks that will allow an LSM to rule on whether or not a watch
      may be set.  More than one hook is required as the watches watch different
      types of object.
      
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Acked-by: default avatarJames Morris <jamorris@linux.microsoft.com>
      cc: Casey Schaufler <casey@schaufler-ca.com>
      cc: Stephen Smalley <sds@tycho.nsa.gov>
      cc: linux-security-module@vger.kernel.org
      998f5040
    • David Howells's avatar
      security: Add a hook for the point of notification insertion · 344fa64e
      David Howells authored
      
      Add a security hook that allows an LSM to rule on whether a notification
      message is allowed to be inserted into a particular watch queue.
      
      The hook is given the following information:
      
       (1) The credentials of the triggerer (which may be init_cred for a system
           notification, eg. a hardware error).
      
       (2) The credentials of the whoever set the watch.
      
       (3) The notification message.
      
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Acked-by: default avatarJames Morris <jamorris@linux.microsoft.com>
      cc: Casey Schaufler <casey@schaufler-ca.com>
      cc: Stephen Smalley <sds@tycho.nsa.gov>
      cc: linux-security-module@vger.kernel.org
      344fa64e
  11. Mar 29, 2020
  12. Jan 27, 2020
  13. Dec 09, 2019
    • Stephen Smalley's avatar
      security,lockdown,selinux: implement SELinux lockdown · 59438b46
      Stephen Smalley authored
      
      Implement a SELinux hook for lockdown.  If the lockdown module is also
      enabled, then a denial by the lockdown module will take precedence over
      SELinux, so SELinux can only further restrict lockdown decisions.
      The SELinux hook only distinguishes at the granularity of integrity
      versus confidentiality similar to the lockdown module, but includes the
      full lockdown reason as part of the audit record as a hint in diagnosing
      what triggered the denial.  To support this auditing, move the
      lockdown_reasons[] string array from being private to the lockdown
      module to the security framework so that it can be used by the lsm audit
      code and so that it is always available even when the lockdown module
      is disabled.
      
      Note that the SELinux implementation allows the integrity and
      confidentiality reasons to be controlled independently from one another.
      Thus, in an SELinux policy, one could allow operations that specify
      an integrity reason while blocking operations that specify a
      confidentiality reason. The SELinux hook implementation is
      stricter than the lockdown module in validating the provided reason value.
      
      Sample AVC audit output from denials:
      avc:  denied  { integrity } for pid=3402 comm="fwupd"
       lockdown_reason="/dev/mem,kmem,port" scontext=system_u:system_r:fwupd_t:s0
       tcontext=system_u:system_r:fwupd_t:s0 tclass=lockdown permissive=0
      
      avc:  denied  { confidentiality } for pid=4628 comm="cp"
       lockdown_reason="/proc/kcore access"
       scontext=unconfined_u:unconfined_r:test_lockdown_integrity_t:s0-s0:c0.c1023
       tcontext=unconfined_u:unconfined_r:test_lockdown_integrity_t:s0-s0:c0.c1023
       tclass=lockdown permissive=0
      
      Signed-off-by: default avatarStephen Smalley <sds@tycho.nsa.gov>
      Reviewed-by: default avatarJames Morris <jamorris@linux.microsoft.com>
      [PM: some merge fuzz do the the perf hooks]
      Signed-off-by: default avatarPaul Moore <paul@paul-moore.com>
      59438b46
  14. Oct 17, 2019
    • Joel Fernandes (Google)'s avatar
      perf_event: Add support for LSM and SELinux checks · da97e184
      Joel Fernandes (Google) authored
      In current mainline, the degree of access to perf_event_open(2) system
      call depends on the perf_event_paranoid sysctl.  This has a number of
      limitations:
      
      1. The sysctl is only a single value. Many types of accesses are controlled
         based on the single value thus making the control very limited and
         coarse grained.
      2. The sysctl is global, so if the sysctl is changed, then that means
         all processes get access to perf_event_open(2) opening the door to
         security issues.
      
      This patch adds LSM and SELinux access checking which will be used in
      Android to access perf_event_open(2) for the purposes of attaching BPF
      programs to tracepoints, perf profiling and other operations from
      userspace. These operations are intended for production systems.
      
      5 new LSM hooks are added:
      1. perf_event_open: This controls access during the perf_event_open(2)
         syscall itself. The hook is called from all the places that the
         perf_event_paranoid sysctl is checked to keep it consistent with the
         systctl. The hook gets passed a 'type' argument which controls CPU,
         kernel and tracepoint accesses (in this context, CPU, kernel and
         tracepoint have the same semantics as the perf_event_paranoid sysctl).
         Additionally, I added an 'open' type which is similar to
         perf_event_paranoid sysctl == 3 patch carried in Android and several other
         distros but was rejected in mainline [1] in 2016.
      
      2. perf_event_alloc: This allocates a new security object for the event
         which stores the current SID within the event. It will be useful when
         the perf event's FD is passed through IPC to another process which may
         try to read the FD. Appropriate security checks will limit access.
      
      3. perf_event_free: Called when the event is closed.
      
      4. perf_event_read: Called from the read(2) and mmap(2) syscalls for the event.
      
      5. perf_event_write: Called from the ioctl(2) syscalls for the event.
      
      [1] https://lwn.net/Articles/696240/
      
      
      
      Since Peter had suggest LSM hooks in 2016 [1], I am adding his
      Suggested-by tag below.
      
      To use this patch, we set the perf_event_paranoid sysctl to -1 and then
      apply selinux checking as appropriate (default deny everything, and then
      add policy rules to give access to domains that need it). In the future
      we can remove the perf_event_paranoid sysctl altogether.
      
      Suggested-by: default avatarPeter Zijlstra <peterz@infradead.org>
      Co-developed-by: default avatarPeter Zijlstra <peterz@infradead.org>
      Signed-off-by: default avatarJoel Fernandes (Google) <joel@joelfernandes.org>
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Acked-by: default avatarJames Morris <jmorris@namei.org>
      Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
      Cc: rostedt@goodmis.org
      Cc: Yonghong Song <yhs@fb.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Alexei Starovoitov <ast@kernel.org>
      Cc: jeffv@google.com
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Daniel Borkmann <daniel@iogearbox.net>
      Cc: primiano@google.com
      Cc: Song Liu <songliubraving@fb.com>
      Cc: rsavitski@google.com
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Matthew Garrett <matthewgarrett@google.com>
      Link: https://lkml.kernel.org/r/20191014170308.70668-1-joel@joelfernandes.org
      da97e184
  15. Aug 20, 2019
  16. Aug 12, 2019
    • Aaron Goidel's avatar
      fanotify, inotify, dnotify, security: add security hook for fs notifications · ac5656d8
      Aaron Goidel authored
      
      As of now, setting watches on filesystem objects has, at most, applied a
      check for read access to the inode, and in the case of fanotify, requires
      CAP_SYS_ADMIN. No specific security hook or permission check has been
      provided to control the setting of watches. Using any of inotify, dnotify,
      or fanotify, it is possible to observe, not only write-like operations, but
      even read access to a file. Modeling the watch as being merely a read from
      the file is insufficient for the needs of SELinux. This is due to the fact
      that read access should not necessarily imply access to information about
      when another process reads from a file. Furthermore, fanotify watches grant
      more power to an application in the form of permission events. While
      notification events are solely, unidirectional (i.e. they only pass
      information to the receiving application), permission events are blocking.
      Permission events make a request to the receiving application which will
      then reply with a decision as to whether or not that action may be
      completed. This causes the issue of the watching application having the
      ability to exercise control over the triggering process. Without drawing a
      distinction within the permission check, the ability to read would imply
      the greater ability to control an application. Additionally, mount and
      superblock watches apply to all files within the same mount or superblock.
      Read access to one file should not necessarily imply the ability to watch
      all files accessed within a given mount or superblock.
      
      In order to solve these issues, a new LSM hook is implemented and has been
      placed within the system calls for marking filesystem objects with inotify,
      fanotify, and dnotify watches. These calls to the hook are placed at the
      point at which the target path has been resolved and are provided with the
      path struct, the mask of requested notification events, and the type of
      object on which the mark is being set (inode, superblock, or mount). The
      mask and obj_type have already been translated into common FS_* values
      shared by the entirety of the fs notification infrastructure. The path
      struct is passed rather than just the inode so that the mount is available,
      particularly for mount watches. This also allows for use of the hook by
      pathname-based security modules. However, since the hook is intended for
      use even by inode based security modules, it is not placed under the
      CONFIG_SECURITY_PATH conditional. Otherwise, the inode-based security
      modules would need to enable all of the path hooks, even though they do not
      use any of them.
      
      This only provides a hook at the point of setting a watch, and presumes
      that permission to set a particular watch implies the ability to receive
      all notification about that object which match the mask. This is all that
      is required for SELinux. If other security modules require additional hooks
      or infrastructure to control delivery of notification, these can be added
      by them. It does not make sense for us to propose hooks for which we have
      no implementation. The understanding that all notifications received by the
      requesting application are all strictly of a type for which the application
      has been granted permission shows that this implementation is sufficient in
      its coverage.
      
      Security modules wishing to provide complete control over fanotify must
      also implement a security_file_open hook that validates that the access
      requested by the watching application is authorized. Fanotify has the issue
      that it returns a file descriptor with the file mode specified during
      fanotify_init() to the watching process on event. This is already covered
      by the LSM security_file_open hook if the security module implements
      checking of the requested file mode there. Otherwise, a watching process
      can obtain escalated access to a file for which it has not been authorized.
      
      The selinux_path_notify hook implementation works by adding five new file
      permissions: watch, watch_mount, watch_sb, watch_reads, and watch_with_perm
      (descriptions about which will follow), and one new filesystem permission:
      watch (which is applied to superblock checks). The hook then decides which
      subset of these permissions must be held by the requesting application
      based on the contents of the provided mask and the obj_type. The
      selinux_file_open hook already checks the requested file mode and therefore
      ensures that a watching process cannot escalate its access through
      fanotify.
      
      The watch, watch_mount, and watch_sb permissions are the baseline
      permissions for setting a watch on an object and each are a requirement for
      any watch to be set on a file, mount, or superblock respectively. It should
      be noted that having either of the other two permissions (watch_reads and
      watch_with_perm) does not imply the watch, watch_mount, or watch_sb
      permission. Superblock watches further require the filesystem watch
      permission to the superblock. As there is no labeled object in view for
      mounts, there is no specific check for mount watches beyond watch_mount to
      the inode. Such a check could be added in the future, if a suitable labeled
      object existed representing the mount.
      
      The watch_reads permission is required to receive notifications from
      read-exclusive events on filesystem objects. These events include accessing
      a file for the purpose of reading and closing a file which has been opened
      read-only. This distinction has been drawn in order to provide a direct
      indication in the policy for this otherwise not obvious capability. Read
      access to a file should not necessarily imply the ability to observe read
      events on a file.
      
      Finally, watch_with_perm only applies to fanotify masks since it is the
      only way to set a mask which allows for the blocking, permission event.
      This permission is needed for any watch which is of this type. Though
      fanotify requires CAP_SYS_ADMIN, this is insufficient as it gives implicit
      trust to root, which we do not do, and does not support least privilege.
      
      Signed-off-by: default avatarAaron Goidel <acgoide@tycho.nsa.gov>
      Acked-by: default avatarCasey Schaufler <casey@schaufler-ca.com>
      Acked-by: default avatarJan Kara <jack@suse.cz>
      Signed-off-by: default avatarPaul Moore <paul@paul-moore.com>
      ac5656d8
  17. Jun 14, 2019
  18. May 30, 2019
  19. Mar 21, 2019
    • Ondrej Mosnacek's avatar
      LSM: add new hook for kernfs node initialization · b230d5ab
      Ondrej Mosnacek authored
      
      This patch introduces a new security hook that is intended for
      initializing the security data for newly created kernfs nodes, which
      provide a way of storing a non-default security context, but need to
      operate independently from mounts (and therefore may not have an
      associated inode at the moment of creation).
      
      The main motivation is to allow kernfs nodes to inherit the context of
      the parent under SELinux, similar to the behavior of
      security_inode_init_security(). Other LSMs may implement their own logic
      for handling the creation of new nodes.
      
      This patch also adds helper functions to <linux/kernfs.h> for
      getting/setting security xattrs of a kernfs node so that LSMs hooks are
      able to do their job. Other important attributes should be accessible
      direcly in the kernfs_node fields (in case there is need for more, then
      new helpers should be added to kernfs.h along with the patch that needs
      them).
      
      Signed-off-by: default avatarOndrej Mosnacek <omosnace@redhat.com>
      Acked-by: default avatarCasey Schaufler <casey@schaufler-ca.com>
      [PM: more manual merge fixes]
      Signed-off-by: default avatarPaul Moore <paul@paul-moore.com>
      b230d5ab
  20. Mar 20, 2019
  21. Feb 28, 2019
    • Al Viro's avatar
      introduce cloning of fs_context · 0b52075e
      Al Viro authored
      
      new primitive: vfs_dup_fs_context().  Comes with fs_context
      method (->dup()) for copying the filesystem-specific parts
      of fs_context, along with LSM one (->fs_context_dup()) for
      doing the same to LSM parts.
      
      [needs better commit message, and change of Author:, anyway]
      
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      0b52075e
    • David Howells's avatar
      vfs: Add LSM hooks for the new mount API · da2441fd
      David Howells authored
      
      Add LSM hooks for use by the new mount API and filesystem context code.
      This includes:
      
       (1) Hooks to handle allocation, duplication and freeing of the security
           record attached to a filesystem context.
      
       (2) A hook to snoop source specifications.  There may be multiple of these
           if the filesystem supports it.  They will to be local files/devices if
           fs_context::source_is_dev is true and will be something else, possibly
           remote server specifications, if false.
      
       (3) A hook to snoop superblock configuration options in key[=val] form.
           If the LSM decides it wants to handle it, it can suppress the option
           being passed to the filesystem.  Note that 'val' may include commas
           and binary data with the fsopen patch.
      
       (4) A hook to perform validation and allocation after the configuration
           has been done but before the superblock is allocated and set up.
      
       (5) A hook to transfer the security from the context to a newly created
           superblock.
      
       (6) A hook to rule on whether a path point can be used as a mountpoint.
      
      These are intended to replace:
      
      	security_sb_copy_data
      	security_sb_kern_mount
      	security_sb_mount
      	security_sb_set_mnt_opts
      	security_sb_clone_mnt_opts
      	security_sb_parse_opts_str
      
      [AV -- some of the methods being replaced are already gone, some of the
      methods are not added for the lack of need]
      
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      cc: linux-security-module@vger.kernel.org
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      da2441fd
  22. Feb 25, 2019
  23. Feb 01, 2019
  24. Jan 18, 2019
  25. Jan 16, 2019
  26. Jan 10, 2019
  27. Jan 08, 2019
Loading