- Oct 17, 2020
-
-
Jens Axboe authored
A previous commit changed the notification mode from true/false to an int, allowing notify-no, notify-yes, or signal-notify. This was backwards compatible in the sense that any existing true/false user would translate to either 0 (on notification sent) or 1, the latter which mapped to TWA_RESUME. TWA_SIGNAL was assigned a value of 2. Clean this up properly, and define a proper enum for the notification mode. Now we have: - TWA_NONE. This is 0, same as before the original change, meaning no notification requested. - TWA_RESUME. This is 1, same as before the original change, meaning that we use TIF_NOTIFY_RESUME. - TWA_SIGNAL. This uses TIF_SIGPENDING/JOBCTL_TASK_WORK for the notification. Clean up all the callers, switching their 0/1/false/true to using the appropriate TWA_* mode for notifications. Fixes: e91b4816 ("task_work: teach task_work_add() to do signal_wake_up()") Reviewed-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
Jens Axboe <axboe@kernel.dk>
-
- Apr 27, 2020
-
-
Instead of having all the sysctl handlers deal with user pointers, which is rather hairy in terms of the BPF interaction, copy the input to and from userspace in common code. This also means that the strings are always NUL-terminated by the common code, making the API a little bit safer. As most handler just pass through the data to one of the common handlers a lot of the changes are mechnical. Signed-off-by:
Christoph Hellwig <hch@lst.de> Acked-by:
Andrey Ignatov <rdna@fb.com> Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk>
-
- Jul 19, 2019
-
-
Matteo Croce authored
In the sysctl code the proc_dointvec_minmax() function is often used to validate the user supplied value between an allowed range. This function uses the extra1 and extra2 members from struct ctl_table as minimum and maximum allowed value. On sysctl handler declaration, in every source file there are some readonly variables containing just an integer which address is assigned to the extra1 and extra2 members, so the sysctl range is enforced. The special values 0, 1 and INT_MAX are very often used as range boundary, leading duplication of variables like zero=0, one=1, int_max=INT_MAX in different source files: $ git grep -E '\.extra[12].*&(zero|one|int_max)' |wc -l 248 Add a const int array containing the most commonly used values, some macros to refer more easily to the correct array member, and use them instead of creating a local one for every object file. This is the bloat-o-meter output comparing the old and new binary compiled with the default Fedora config: # scripts/bloat-o-meter -d vmlinux.o.old vmlinux.o add/remove: 2/2 grow/shrink: 0/2 up/down: 24/-188 (-164) Data old new delta sysctl_vals - 12 +12 __kstrtab_sysctl_vals - 12 +12 max 14 10 -4 int_max 16 - -16 one 68 - -68 zero 128 28 -100 Total: Before=20583249, After=20583085, chg -0.00% [mcroce@redhat.com: tipc: remove two unused variables] Link: http://lkml.kernel.org/r/20190530091952.4108-1-mcroce@redhat.com [akpm@linux-foundation.org: fix net/ipv6/sysctl_net_ipv6.c] [arnd@arndb.de: proc/sysctl: make firmware loader table conditional] Link: http://lkml.kernel.org/r/20190617130014.1713870-1-arnd@arndb.de [akpm@linux-foundation.org: fix fs/eventpoll.c] Link: http://lkml.kernel.org/r/20190430180111.10688-1-mcroce@redhat.com Signed-off-by:Matteo Croce <mcroce@redhat.com> Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Acked-by:
Kees Cook <keescook@chromium.org> Reviewed-by:
Aaron Tomlin <atomlin@redhat.com> Cc: Matthew Wilcox <willy@infradead.org> Cc: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
- Jun 19, 2019
-
-
Thomas Gleixner authored
Based on 2 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 version 2 as published by the free software foundation this program is free software you can redistribute it and or modify it under the terms of the gnu general public license version 2 as published by the free software foundation # extracted by the scancode license scanner the SPDX license identifier GPL-2.0-only has been chosen to replace the boilerplate/reference in 4122 file(s). Signed-off-by:
Enrico Weigelt <info@metux.net>
Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org> Reviewed-by:
Allison Randal <allison@lohutok.net> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190604081206.933168790@linutronix.de Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- May 21, 2019
-
-
Thomas Gleixner authored
Add SPDX license identifiers to all Make/Kconfig files which: - Have no license information of any form These files fall under the project license, GPL v2 only. The resulting SPDX license identifier is: GPL-2.0-only Signed-off-by:
-
- Apr 10, 2019
-
-
Mukesh Ojha authored
Sparse complains yama_task_prctl can be static. Fix it by making it static. Signed-off-by:
Mukesh Ojha <mojha@codeaurora.org> Signed-off-by:
James Morris <james.morris@microsoft.com>
-
Jann Horn authored
sparse complains that Yama defines functions and a variable as non-static even though they don't exist in any header. Fix it by making them static. Signed-off-by:
Jann Horn <jannh@google.com> Reviewed-by:
-
- Mar 28, 2019
-
-
Jann Horn authored
sparse complains that Yama defines functions and a variable as non-static even though they don't exist in any header. Fix it by making them static. Co-developed-by:
-
- Jan 16, 2019
-
-
Kees Cook authored
It's possible that a pid has died before we take the rcu lock, in which case we can't walk the ancestry list as it may be detached. Instead, check for death first before doing the walk. Reported-by:
<syzbot+a9ac39bf55329e206219@syzkaller.appspotmail.com> Fixes: 2d514487 ("security: Yama LSM") Cc: stable@vger.kernel.org Suggested-by:
Oleg Nesterov <oleg@redhat.com> Signed-off-by:
-
- Jan 08, 2019
-
-
Kees Cook authored
This converts Yama from being a direct "minor" LSM into an ordered LSM. Signed-off-by:
Casey Schaufler <casey@schaufler-ca.com>
-
- Feb 07, 2018
-
-
Mike Rapoport authored
There are several functions that do find_task_by_vpid() followed by get_task_struct(). We can use a helper function instead. Link: http://lkml.kernel.org/r/1509602027-11337-1-git-send-email-rppt@linux.vnet.ibm.com Signed-off-by:
Mike Rapoport <rppt@linux.vnet.ibm.com> Acked-by:
-
- May 18, 2017
-
-
Kees Cook authored
Adjusts for ReST markup and moves under LSM admin guide. Signed-off-by:
Jonathan Corbet <corbet@lwn.net>
-
- Mar 06, 2017
-
-
James Morris authored
Mark all of the registration hooks as __ro_after_init (via the __lsm_ro_after_init macro). Signed-off-by:
James Morris <james.l.morris@oracle.com> Acked-by:
Stephen Smalley <sds@tycho.nsa.gov> Acked-by:
-
- Jan 19, 2017
-
-
Casey Schaufler authored
I am still tired of having to find indirect ways to determine what security modules are active on a system. I have added /sys/kernel/security/lsm, which contains a comma separated list of the active security modules. No more groping around in /proc/filesystems or other clever hacks. Unchanged from previous versions except for being updated to the latest security next branch. Signed-off-by:
John Johansen <john.johansen@canonical.com> Acked-by:
Paul Moore <paul@paul-moore.com> Acked-by:
-
- Dec 05, 2016
-
-
Josh Stone authored
Under ptrace_scope=1, it's possible to have a tracee that is already ptrace-attached, but is no longer a direct descendant. For instance, a forking daemon will be re-parented to init, losing its ancestry to the tracer that launched it. The tracer can continue using ptrace in that state, but it will be denied other accesses that check PTRACE_MODE_ATTACH, like process_vm_rw and various procfs files. There's no reason to prevent such access for a tracer that already has ptrace control anyway. This patch adds a case to ptracer_exception_found to allow access for any task in the same thread group as the current ptrace parent. Signed-off-by:
Josh Stone <jistone@redhat.com> Cc: Kees Cook <keescook@chromium.org> Cc: James Morris <james.l.morris@oracle.com> Cc: "Serge E. Hallyn" <serge@hallyn.com> Cc: linux-security-module@vger.kernel.org Signed-off-by:
-
- May 25, 2016
-
-
Jann Horn authored
Commit 8a56038c ("Yama: consolidate error reporting") causes lockups when someone hits a Yama denial. Call chain: process_vm_readv -> process_vm_rw -> process_vm_rw_core -> mm_access -> ptrace_may_access task_lock(...) is taken __ptrace_may_access -> security_ptrace_access_check -> yama_ptrace_access_check -> report_access -> kstrdup_quotable_cmdline -> get_cmdline -> access_process_vm -> get_task_mm task_lock(...) is taken again task_lock(p) just calls spin_lock(&p->alloc_lock), so at this point, spin_lock() is called on a lock that is already held by the current process. Also: Since the alloc_lock is a spinlock, sleeping inside security_ptrace_access_check hooks is probably not allowed at all? So it's not even possible to print the cmdline from in there because that might involve paging in userspace memory. It would be tempting to rewrite ptrace_may_access() to drop the alloc_lock before calling the LSM, but even then, ptrace_may_access() itself might be called from various contexts in which you're not allowed to sleep; for example, as far as I understand, to be able to hold a reference to another task, usually an RCU read lock will be taken (see e.g. kcmp() and get_robust_list()), so that also prohibits sleeping. (And using e.g. FUSE, a user can cause pagefault handling to take arbitrary amounts of time - see https://bugs.chromium.org/p/project-zero/issues/detail?id=808. ) Therefore, AFAIK, in order to print the name of a process below security_ptrace_access_check(), you'd have to either grab a reference to the mm_struct and defer the access violation reporting or just use the "comm" value that's stored in kernelspace and accessible without big complications. (Or you could try to use some kind of atomic remote VM access that fails if the memory isn't paged in, similar to copy_from_user_inatomic(), and if necessary fall back to comm, but that'd be kind of ugly because the comm/cmdline choice would look pretty random to the user.) Fix it by deferring reporting of the access violation until current exits kernelspace the next time. v2: Don't oops on PTRACE_TRACEME, call report_access under task_lock(current). Also fix nonsensical comment. And don't use GPF_ATOMIC for memory allocation with no locks held. This patch is tested both for ptrace attach and ptrace traceme. Fixes: 8a56038c ("Yama: consolidate error reporting") Signed-off-by:
Jann Horn <jann@thejh.net> Acked-by:
-
- May 04, 2016
-
-
Sasha Levin authored
Access reporting often happens from atomic contexes. Avoid lockups when allocating memory for command lines. Fixes: 8a56038c ("Yama: consolidate error reporting") Signed-off-by:
Sasha Levin <sasha.levin@oracle.com>
-
- Apr 21, 2016
-
-
Kees Cook authored
Use a common error reporting function for Yama violation reports, and give more detail into the process command lines. Signed-off-by:
-
- Jan 21, 2016
-
-
Jann Horn authored
It looks like smack and yama weren't aware that the ptrace mode can have flags ORed into it - PTRACE_MODE_NOAUDIT until now, but only for /proc/$pid/stat, and with the PTRACE_MODE_*CREDS patch, all modes have flags ORed into them. Signed-off-by:
-
- Aug 03, 2015
-
-
Salvatore Mesoraca authored
Without this patch YAMA will not work at all if it is chosen as the primary LSM instead of being "stacked". Signed-off-by:
Salvatore Mesoraca <s.mesoraca16@gmail.com> Acked-by:
-
- Jul 28, 2015
-
-
Kees Cook authored
Now that minor LSMs can cleanly stack with major LSMs, remove the unneeded config for Yama to be made to explicitly stack. Just selecting the main Yama CONFIG will allow it to work, regardless of the major LSM. Since distros using Yama are already forcing it to stack, this is effectively a no-op change. Additionally add MAINTAINERS entry. Signed-off-by:
-
- May 12, 2015
-
-
Casey Schaufler authored
Instead of using a vector of security operations with explicit, special case stacking of the capability and yama hooks use lists of hooks with capability and yama hooks included as appropriate. The security_operations structure is no longer required. Instead, there is a union of the function pointers that allows all the hooks lists to use a common mechanism for list management while retaining typing. Each module supplies an array describing the hooks it provides instead of a sparsely populated security_operations structure. The description includes the element that gets put on the hook list, avoiding the issues surrounding individual element allocation. The method for registering security modules is changed to reflect the information available. The method for removing a module, currently only used by SELinux, has also changed. It should be generic now, however if there are potential race conditions based on ordering of hook removal that needs to be addressed by the calling module. The security hooks are called from the lists and the first failure is returned. Signed-off-by:
Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Signed-off-by:
-
Casey Schaufler authored
Add a list header for each security hook. They aren't used until later in the patch series. They are grouped together in a structure so that there doesn't need to be an external address for each. Macro-ize the initialization of the security_operations for each security module in anticipation of changing out the security_operations structure. Signed-off-by:
-
Casey Schaufler authored
The security.h header file serves two purposes, interfaces for users of the security modules and interfaces for security modules. Users of the security modules don't need to know about what's in the security_operations structure, so pull it out into it's own header, lsm_hooks.h Signed-off-by:
-
- Feb 28, 2015
-
-
Stephen Smalley authored
Yama selects SECURITYFS and SECURITY_PATH, but requires neither. Remove them. Signed-off-by:
-
Kees Cook authored
When the sysctl table is constified, we won't be able to directly modify it. Instead, use a table copy that carries any needed changes. Suggested-by:
PaX Team <pageexec@freemail.hu> Signed-off-by:
-
- Mar 26, 2013
-
-
Eric W. Biederman authored
Change the permission check for yama_ptrace_ptracee to the standard ptrace permission check, testing if the traceer has CAP_SYS_PTRACE in the tracees user namespace. Reviewed-by:
"Eric W. Biederman" <ebiederm@xmission.com>
-
- Nov 20, 2012
-
-
Kees Cook authored
Instead of locking the list during a delete, mark entries as invalid and trigger a workqueue to clean them up. This lets us easily handle task_free from interrupt context. Signed-off-by: -
Kees Cook authored
Stop using spinlocks in the read path. Add RCU list to handle the readers. Signed-off-by:
Serge E. Hallyn <serge.hallyn@ubuntu.com> Acked-by:
-
Eric W. Biederman authored
The task_user_ns function hides the fact that it is getting the user namespace from struct cred on the task. struct cred may go away as soon as the rcu lock is released. This leads to a race where we can dereference a stale user namespace pointer. To make it obvious a struct cred is involved kill task_user_ns. To kill the race modify the users of task_user_ns to only reference the user namespace while the rcu lock is held. Cc: Kees Cook <keescook@chromium.org> Cc: James Morris <james.l.morris@oracle.com> Acked-by:
Serge Hallyn <serge.hallyn@canonical.com> Signed-off-by:
-
- Sep 07, 2012
-
-
Kees Cook authored
When running a 64-bit kernel and receiving prctls from a 32-bit userspace, the "-1" used as an unsigned long will end up being misdetected. The kernel is looking for 0xffffffffffffffff instead of 0xffffffff. Since prctl lacks a distinct compat interface, Yama needs to handle this translation itself. As such, support either value as meaning PR_SET_PTRACER_ANY, to avoid breaking the ABI for 64-bit. Signed-off-by:
-
- Sep 05, 2012
-
-
Kees Cook authored
Unconditionally call Yama when CONFIG_SECURITY_YAMA_STACKED is selected, no matter what LSM module is primary. Ubuntu and Chrome OS already carry patches to do this, and Fedora has voiced interest in doing this as well. Instead of having multiple distributions (or LSM authors) carrying these patches, just allow Yama to be called unconditionally when selected by the new CONFIG. Signed-off-by:
Eric Paris <eparis@redhat.com> Acked-by:
-
- Aug 17, 2012
-
-
Kees Cook authored
The core ptrace access checking routine holds a task lock, and when reporting a failure, Yama takes a separate task lock. To avoid a potential deadlock with two ptracers taking the opposite locks, do not use get_task_comm() and just use ->comm directly since accuracy is not important for the report. Reported-by:
Fengguang Wu <fengguang.wu@intel.com> Suggested-by:
-
- Aug 10, 2012
-
-
Kees Cook authored
The higher ptrace restriction levels should be blocking even PTRACE_TRACEME requests. The comments in the LSM documentation are misleading about when the checks happen (the parent does not go through security_ptrace_access_check() on a PTRACE_TRACEME call). Signed-off-by:
-
- May 15, 2012
-
-
Kees Cook authored
When checking capabilities, the question we want to be asking is "does current() have the capability in the child's namespace?" Signed-off-by:
-
- Apr 23, 2012
-
-
Dan Carpenter authored
GCC complains that we don't use "one" any more after 389da25f "Yama: add additional ptrace scopes". security/yama/yama_lsm.c:322:12: warning: ?one? defined but not used [-Wunused-variable] Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Acked-by:
-
- Apr 19, 2012
-
-
Kees Cook authored
This expands the available Yama ptrace restrictions to include two more modes. Mode 2 requires CAP_SYS_PTRACE for PTRACE_ATTACH, and mode 3 completely disables PTRACE_ATTACH (and locks the sysctl). Signed-off-by:
-
- Feb 15, 2012
-
-
Kees Cook authored
For a process to entirely disable Yama ptrace restrictions, it can use the special PR_SET_PTRACER_ANY pid to indicate that any otherwise allowed process may ptrace it. This is stronger than calling PR_SET_PTRACER with pid "1" because it includes processes in external pid namespaces. This is currently needed by the Chrome renderer, since its crash handler (Breakpad) runs external to the renderer's pid namespace. Signed-off-by:
James Morris <jmorris@namei.org>
-
- Feb 09, 2012
-
-
Kees Cook authored
This adds the Yama Linux Security Module to collect DAC security improvements (specifically just ptrace restrictions for now) that have existed in various forms over the years and have been carried outside the mainline kernel by other Linux distributions like Openwall and grsecurity. Signed-off-by:
-
