- Aug 15, 2021
-
-
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:
Daniel Borkmann <daniel@iogearbox.net> Acked-by:
Andrii Nakryiko <andrii@kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- Oct 05, 2020
-
-
Kees Cook authored
As with the kernel_load_data LSM hook, add a "contents" flag to the kernel_read_file LSM hook that indicates whether the LSM can expect a matching call to the kernel_post_read_file LSM hook with the full contents of the file. With the coming addition of partial file read support for kernel_read_file*() API, the LSM will no longer be able to always see the entire contents of a file during the read calls. For cases where the LSM must read examine the complete file contents, it will need to do so on its own every time the kernel_read_file hook is called with contents=false (or reject such cases). Adjust all existing LSMs to retain existing behavior. Signed-off-by:
Kees Cook <keescook@chromium.org> Reviewed-by:
Mimi Zohar <zohar@linux.ibm.com> Link: https://lore.kernel.org/r/20201002173828.2099543-12-keescook@chromium.org Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Kees Cook authored
There are a few places in the kernel where LSMs would like to have visibility into the contents of a kernel buffer that has been loaded or read. While security_kernel_post_read_file() (which includes the buffer) exists as a pairing for security_kernel_read_file(), no such hook exists to pair with security_kernel_load_data(). Earlier proposals for just using security_kernel_post_read_file() with a NULL file argument were rejected (i.e. "file" should always be valid for the security_..._file hooks, but it appears at least one case was left in the kernel during earlier refactoring. (This will be fixed in a subsequent patch.) Since not all cases of security_kernel_load_data() can have a single contiguous buffer made available to the LSM hook (e.g. kexec image segments are separately loaded), there needs to be a way for the LSM to reason about its expectations of the hook coverage. In order to handle this, add a "contents" argument to the "kernel_load_data" hook that indicates if the newly added "kernel_post_load_data" hook will be called with the full contents once loaded. That way, LSMs requiring full contents can choose to unilaterally reject "kernel_load_data" with contents=false (which is effectively the existing hook coverage), but when contents=true they can allow it and later evaluate the "kernel_post_load_data" hook once the buffer is loaded. With this change, LSMs can gain coverage over non-file-backed data loads (e.g. init_module(2) and firmware userspace helper), which will happen in subsequent patches. Additionally prepare IMA to start processing these cases. Signed-off-by:
Kees Cook <keescook@chromium.org> Reviewed-by:
KP Singh <kpsingh@google.com> Link: https://lore.kernel.org/r/20201002173828.2099543-9-keescook@chromium.org Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Scott Branden authored
Move kernel_read_file* out of linux/fs.h to its own linux/kernel_read_file.h include file. That header gets pulled in just about everywhere and doesn't really need functions not related to the general fs interface. Suggested-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
Scott Branden <scott.branden@broadcom.com> Signed-off-by:
Kees Cook <keescook@chromium.org> Reviewed-by:
Christoph Hellwig <hch@lst.de> Reviewed-by:
Mimi Zohar <zohar@linux.ibm.com> Reviewed-by:
Luis Chamberlain <mcgrof@kernel.org> Acked-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by:
James Morris <jamorris@linux.microsoft.com> Link: https://lore.kernel.org/r/20200706232309.12010-2-scott.branden@broadcom.com Link: https://lore.kernel.org/r/20201002173828.2099543-4-keescook@chromium.org Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- Jun 23, 2020
-
-
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:
KP Singh <kpsingh@google.com> Signed-off-by:
James Morris <jmorris@namei.org>
-
- Jun 14, 2020
-
-
Thomas Cedeno authored
The SafeSetID LSM uses the security_task_fix_setuid hook to filter set*uid() syscalls according to its configured security policy. In preparation for adding analagous support in the LSM for set*gid() syscalls, we add the requisite hook here. Tested by putting print statements in the security_task_fix_setgid hook and seeing them get hit during kernel boot. Signed-off-by:
Thomas Cedeno <thomascedeno@google.com> Signed-off-by:
Micah Morton <mortonm@chromium.org>
-
- Jun 03, 2020
-
-
Miklos Szeredi authored
Verify LSM permissions for underlying file, since vfs_ioctl() doesn't do it. [Stephen Rothwell] export security_file_ioctl Signed-off-by:
Miklos Szeredi <mszeredi@redhat.com>
-
- May 30, 2020
-
-
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:
Kees Cook <keescook@chromium.org> Signed-off-by:
"Eric W. Biederman" <ebiederm@xmission.com>
-
- May 22, 2020
-
-
Mimi Zohar authored
Files can be mmap'ed read/write and later changed to execute to circumvent IMA's mmap appraise policy rules. Due to locking issues (mmap semaphore would be taken prior to i_mutex), files can not be measured or appraised at this point. Eliminate this integrity gap, by denying the mprotect PROT_EXECUTE change, if an mmap appraise policy rule exists. On mprotect change success, return 0. On failure, return -EACESS. Reviewed-by:
Lakshmi Ramasubramanian <nramas@linux.microsoft.com> Signed-off-by:
Mimi Zohar <zohar@linux.ibm.com>
-
- May 21, 2020
-
-
Eric W. Biederman authored
Rename bprm->cap_elevated to bprm->active_secureexec and initialize it in prepare_binprm instead of in cap_bprm_set_creds. Initializing bprm->active_secureexec in prepare_binprm allows multiple implementations of security_bprm_repopulate_creds to play nicely with each other. Rename security_bprm_set_creds to security_bprm_reopulate_creds to emphasize that this path recomputes part of bprm->cred. This recomputation avoids the time of check vs time of use problems that are inherent in unix #! interpreters. In short two renames and a move in the location of initializing bprm->active_secureexec. Link: https://lkml.kernel.org/r/87o8qkzrxp.fsf_-_@x220.int.ebiederm.org Acked-by:
Linus Torvalds <torvalds@linux-foundation.org> Reviewed-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
"Eric W. Biederman" <ebiederm@xmission.com>
-
KP Singh authored
secid_to_secctx is not stackable, and since the BPF LSM registers this hook by default, the call_int_hook logic is not suitable which "bails-on-fail" and casues issues when other LSMs register this hook and eventually breaks Audit. In order to fix this, directly iterate over the security hooks instead of using call_int_hook as suggested in: https: //lore.kernel.org/bpf/9d0eb6c6-803a-ff3a-5603-9ad6d9edfc00@schaufler-ca.com/#t Fixes: 98e828a0 ("security: Refactor declaration of LSM hooks") Fixes: 625236ba ("security: Fix the default value of secid_to_secctx hook") Reported-by:
Alexei Starovoitov <ast@kernel.org> Signed-off-by:
KP Singh <kpsingh@google.com> Signed-off-by:
Alexei Starovoitov <ast@kernel.org> Acked-by:
James Morris <jamorris@linux.microsoft.com> Link: https://lore.kernel.org/bpf/20200520125616.193765-1-kpsingh@chromium.org
-
- May 20, 2020
-
-
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:
Linus Torvalds <torvalds@linux-foundation.org> Acked-by: Casey Schaufler <casey@schaufler-ca.com> # For the LSM and Smack bits Reviewed-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
"Eric W. Biederman" <ebiederm@xmission.com>
-
- May 19, 2020
-
-
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:
David 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
-
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:
David Howells <dhowells@redhat.com> Acked-by:
James 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
-
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:
David Howells <dhowells@redhat.com> Acked-by:
James 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
-
- Mar 29, 2020
-
-
KP Singh authored
The information about the different types of LSM hooks is scattered in two locations i.e. union security_list_options and struct security_hook_heads. Rather than duplicating this information even further for BPF_PROG_TYPE_LSM, define all the hooks with the LSM_HOOK macro in lsm_hook_defs.h which is then used to generate all the data structures required by the LSM framework. The LSM hooks are defined as: LSM_HOOK(<return_type>, <default_value>, <hook_name>, args...) with <default_value> acccessible in security.c as: LSM_RET_DEFAULT(<hook_name>) Signed-off-by:
KP Singh <kpsingh@google.com> Signed-off-by:
Daniel Borkmann <daniel@iogearbox.net> Reviewed-by:
Brendan Jackman <jackmanb@google.com> Reviewed-by:
Florent Revest <revest@google.com> Reviewed-by:
Kees Cook <keescook@chromium.org> Reviewed-by:
Casey Schaufler <casey@schaufler-ca.com> Acked-by:
James Morris <jamorris@linux.microsoft.com> Link: https://lore.kernel.org/bpf/20200329004356.27286-3-kpsingh@chromium.org
-
- Jan 27, 2020
-
-
Alex Shi authored
This macro is never used from it was introduced in commit e6b1db98 ("security: Support early LSMs"), better to remove it. Signed-off-by:
Alex Shi <alex.shi@linux.alibaba.com> Acked-by:
Serge Hallyn <serge@hallyn.com> Signed-off-by:
James Morris <jmorris@namei.org>
-
- Dec 09, 2019
-
-
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:
Stephen Smalley <sds@tycho.nsa.gov> Reviewed-by:
James Morris <jamorris@linux.microsoft.com> [PM: some merge fuzz do the the perf hooks] Signed-off-by:
Paul Moore <paul@paul-moore.com>
-
- Oct 17, 2019
-
-
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:
Peter Zijlstra <peterz@infradead.org> Co-developed-by:
Peter Zijlstra <peterz@infradead.org> Signed-off-by:
Joel Fernandes (Google) <joel@joelfernandes.org> Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by:
James 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
-
- Aug 20, 2019
-
-
Matthew Garrett authored
Add a mechanism to allow LSMs to make a policy decision around whether kernel functionality that would allow tampering with or examining the runtime state of the kernel should be permitted. Signed-off-by:
Matthew Garrett <mjg59@google.com> Acked-by:
Kees Cook <keescook@chromium.org> Acked-by:
Casey Schaufler <casey@schaufler-ca.com> Signed-off-by:
James Morris <jmorris@namei.org>
-
Matthew Garrett authored
The lockdown module is intended to allow for kernels to be locked down early in boot - sufficiently early that we don't have the ability to kmalloc() yet. Add support for early initialisation of some LSMs, and then add them to the list of names when we do full initialisation later. Early LSMs are initialised in link order and cannot be overridden via boot parameters, and cannot make use of kmalloc() (since the allocator isn't initialised yet). (Fixed by Stephen Rothwell to include a stub to fix builds when !CONFIG_SECURITY) Signed-off-by:
Matthew Garrett <mjg59@google.com> Acked-by:
Kees Cook <keescook@chromium.org> Acked-by:
Casey Schaufler <casey@schaufler-ca.com> Cc: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by:
James Morris <jmorris@namei.org>
-
- Aug 12, 2019
-
-
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:
Aaron Goidel <acgoide@tycho.nsa.gov> Acked-by:
Casey Schaufler <casey@schaufler-ca.com> Acked-by:
Jan Kara <jack@suse.cz> Signed-off-by:
Paul Moore <paul@paul-moore.com>
-
- Jun 14, 2019
-
-
Janne Karhunen authored
Atomic policy updaters are not very useful as they cannot usually perform the policy updates on their own. Since it seems that there is no strict need for the atomicity, switch to the blocking variant. While doing so, rename the functions accordingly. Signed-off-by:
Janne Karhunen <janne.karhunen@gmail.com> Acked-by:
Paul Moore <paul@paul-moore.com> Acked-by:
James Morris <jamorris@linux.microsoft.com> Signed-off-by:
Mimi Zohar <zohar@linux.ibm.com>
-
- May 30, 2019
-
-
Thomas Gleixner authored
Based on 1 normalized pattern(s): this program is free software you can redistribute it and or modify it under the terms of the gnu general public license as published by the free software foundation either version 2 of the license or at your option any later version extracted by the scancode license scanner the SPDX license identifier GPL-2.0-or-later has been chosen to replace the boilerplate/reference in 3029 file(s). Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Reviewed-by:
Allison Randal <allison@lohutok.net> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190527070032.746973796@linutronix.de Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- Mar 21, 2019
-
-
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:
Ondrej Mosnacek <omosnace@redhat.com> Acked-by:
Casey Schaufler <casey@schaufler-ca.com> [PM: more manual merge fixes] Signed-off-by:
Paul Moore <paul@paul-moore.com>
-
- Mar 20, 2019
-
-
David Howells authored
Add a move_mount() system call that will move a mount from one place to another and, in the next commit, allow to attach an unattached mount tree. The new system call looks like the following: int move_mount(int from_dfd, const char *from_path, int to_dfd, const char *to_path, unsigned int flags); Signed-off-by:
David Howells <dhowells@redhat.com> cc: linux-api@vger.kernel.org Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk>
-
- Feb 28, 2019
-
-
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:
Al Viro <viro@zeniv.linux.org.uk>
-
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:
David Howells <dhowells@redhat.com> cc: linux-security-module@vger.kernel.org Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk>
-
- Feb 25, 2019
-
-
Kees Cook authored
To avoid potential confusion, explicitly ignore "security=" when "lsm=" is used on the command line, and report that it is happening. Suggested-by:
Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp> Signed-off-by:
Kees Cook <keescook@chromium.org> Acked-by:
Casey Schaufler <casey@schaufler-ca.com> Acked-by:
John Johansen <john.johansen@canonical.com> Signed-off-by:
James Morris <james.morris@microsoft.com>
-
- Feb 01, 2019
-
-
Richard Guy Briggs authored
The audit_rule_match() struct audit_context *actx parameter is not used by any in-tree consumers (selinux, apparmour, integrity, smack). The audit context is an internal audit structure that should only be accessed by audit accessor functions. It was part of commit 03d37d25 ("LSM/Audit: Introduce generic Audit LSM hooks") but appears to have never been used. Remove it. Please see the github issue https://github.com/linux-audit/audit-kernel/issues/107 Signed-off-by:
Richard Guy Briggs <rgb@redhat.com> [PM: fixed the referenced commit title] Signed-off-by:
Paul Moore <paul@paul-moore.com>
-
- Jan 18, 2019
-
-
Wei Yongjun authored
Fixes the following sparse warnings: security/security.c:533:5: warning: symbol 'lsm_task_alloc' was not declared. Should it be static? security/security.c:554:5: warning: symbol 'lsm_ipc_alloc' was not declared. Should it be static? security/security.c:575:5: warning: symbol 'lsm_msg_msg_alloc' was not declared. Should it be static? Fixes: f4ad8f2c ("LSM: Infrastructure management of the task security") Signed-off-by:
Wei Yongjun <weiyongjun1@huawei.com> Acked-by:
Casey Schaufler <casey@schaufler-ca.com> Signed-off-by:
James Morris <james.morris@microsoft.com>
-
Tetsuo Handa authored
Since current->cred == current->real_cred when ordered_lsm_init() is called, and lsm_early_cred()/lsm_early_task() need to be called between the amount of required bytes is determined and module specific initialization function is called, we can move these calls from individual modules to ordered_lsm_init(). Signed-off-by:
Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Acked-by:
Casey Schaufler <casey@schaufler-ca.com> Signed-off-by:
James Morris <james.morris@microsoft.com>
-
- Jan 16, 2019
-
-
James Morris authored
From: Casey Schaufler <casey@schaufler-ca.com> Check that the cred security blob has been set before trying to clean it up. There is a case during credential initialization that could result in this. Signed-off-by:
Casey Schaufler <casey@schaufler-ca.com> Acked-by:
John Johansen <john.johansen@canonical.com> Signed-off-by:
James Morris <james.morris@microsoft.com> Reported-by:
<syzbot+69ca07954461f189e808@syzkaller.appspotmail.com>
-
- Jan 10, 2019
-
-
Micah Morton authored
This patch provides a general mechanism for passing flags to the security_capable LSM hook. It replaces the specific 'audit' flag that is used to tell security_capable whether it should log an audit message for the given capability check. The reason for generalizing this flag passing is so we can add an additional flag that signifies whether security_capable is being called by a setid syscall (which is needed by the proposed SafeSetID LSM). Signed-off-by:
Micah Morton <mortonm@chromium.org> Reviewed-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
James Morris <james.morris@microsoft.com>
-
- Jan 08, 2019
-
-
Casey Schaufler authored
Move management of the kern_ipc_perm->security and msg_msg->security blobs out of the individual security modules and into the security infrastructure. Instead of allocating the blobs from within the modules the modules tell the infrastructure how much space is required, and the space is allocated there. Signed-off-by:
Casey Schaufler <casey@schaufler-ca.com> Reviewed-by:
Kees Cook <keescook@chromium.org> [kees: adjusted for ordered init series] Signed-off-by:
Kees Cook <keescook@chromium.org>
-
Casey Schaufler authored
Move management of the task_struct->security blob out of the individual security modules and into the security infrastructure. Instead of allocating the blobs from within the modules the modules tell the infrastructure how much space is required, and the space is allocated there. The only user of this blob is AppArmor. The AppArmor use is abstracted to avoid future conflict. Signed-off-by:
Casey Schaufler <casey@schaufler-ca.com> Reviewed-by:
Kees Cook <keescook@chromium.org> [kees: adjusted for ordered init series] Signed-off-by:
Kees Cook <keescook@chromium.org>
-
Casey Schaufler authored
Move management of the inode->i_security blob out of the individual security modules and into the security infrastructure. Instead of allocating the blobs from within the modules the modules tell the infrastructure how much space is required, and the space is allocated there. Signed-off-by:
Casey Schaufler <casey@schaufler-ca.com> Reviewed-by:
Kees Cook <keescook@chromium.org> [kees: adjusted for ordered init series] Signed-off-by:
Kees Cook <keescook@chromium.org>
-
Casey Schaufler authored
Move management of the file->f_security blob out of the individual security modules and into the infrastructure. The modules no longer allocate or free the data, instead they tell the infrastructure how much space they require. Signed-off-by:
Casey Schaufler <casey@schaufler-ca.com> Reviewed-by:
Kees Cook <keescook@chromium.org> [kees: adjusted for ordered init series] Signed-off-by:
Kees Cook <keescook@chromium.org>
-
Casey Schaufler authored
Move management of the cred security blob out of the security modules and into the security infrastructre. Instead of allocating and freeing space the security modules tell the infrastructure how much space they require. Signed-off-by:
Casey Schaufler <casey@schaufler-ca.com> Reviewed-by:
Kees Cook <keescook@chromium.org> [kees: adjusted for ordered init series] Signed-off-by:
Kees Cook <keescook@chromium.org>
-
Casey Schaufler authored
Back in 2007 I made what turned out to be a rather serious mistake in the implementation of the Smack security module. The SELinux module used an interface in /proc to manipulate the security context on processes. Rather than use a similar interface, I used the same interface. The AppArmor team did likewise. Now /proc/.../attr/current will tell you the security "context" of the process, but it will be different depending on the security module you're using. This patch provides a subdirectory in /proc/.../attr for Smack. Smack user space can use the "current" file in this subdirectory and never have to worry about getting SELinux attributes by mistake. Programs that use the old interface will continue to work (or fail, as the case may be) as before. The proposed S.A.R.A security module is dependent on the mechanism to create its own attr subdirectory. The original implementation is by Kees Cook. Signed-off-by:
Casey Schaufler <casey@schaufler-ca.com> Reviewed-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
Kees Cook <keescook@chromium.org>
-