summaryrefslogtreecommitdiffstats
path: root/security/yama
AgeCommit message (Collapse)AuthorFilesLines
2019-05-21treewide: Add SPDX license identifier - Makefile/KconfigThomas Gleixner2-0/+2
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: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-03-28Yama: mark local symbols as staticJann Horn1-4/+4
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: Mukesh Ojha <mojha@codeaurora.org> Signed-off-by: Mukesh Ojha <mojha@codeaurora.org> Signed-off-by: Jann Horn <jannh@google.com> [kees: merged similar static-ness fixes into a single patch] Link: https://lkml.kernel.org/r/20190326230841.87834-1-jannh@google.com Link: https://lkml.kernel.org/r/1553673018-19234-1-git-send-email-mojha@codeaurora.org Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: James Morris <james.morris@microsoft.com>
2019-01-22Merge tag 'v5.0-rc3' into next-generalJames Morris1-1/+3
Sync to Linux 5.0-rc3 to pull in the VFS changes which impacted a lot of the LSM code.
2019-01-16Yama: Check for pid death before checking ancestryKees Cook1-1/+3
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: 2d514487faf1 ("security: Yama LSM") Cc: stable@vger.kernel.org Suggested-by: Oleg Nesterov <oleg@redhat.com> Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: James Morris <james.morris@microsoft.com>
2019-01-08Yama: Initialize as ordered LSMKees Cook1-1/+7
This converts Yama from being a direct "minor" LSM into an ordered LSM. Signed-off-by: Kees Cook <keescook@chromium.org> Reviewed-by: Casey Schaufler <casey@schaufler-ca.com>
2018-02-06pids: introduce find_get_task_by_vpid() helperMike Rapoport1-8/+3
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: Oleg Nesterov <oleg@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-05-18doc: ReSTify Yama.txtKees Cook1-1/+2
Adjusts for ReST markup and moves under LSM admin guide. Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: Jonathan Corbet <corbet@lwn.net>
2017-03-06security: mark LSM hooks as __ro_after_initJames Morris1-1/+1
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: Kees Cook <keescook@chromium.org>
2017-01-19LSM: Add /sys/kernel/security/lsmCasey Schaufler1-1/+1
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: Casey Schaufler <casey@schaufler-ca.com> Acked-by: John Johansen <john.johansen@canonical.com> Acked-by: Paul Moore <paul@paul-moore.com> Acked-by: Kees Cook <keescook@chromium.org> Signed-off-by: James Morris <james.l.morris@oracle.com>
2016-12-05Yama: allow access for the current ptrace parentJosh Stone1-1/+15
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: Kees Cook <keescook@chromium.org> Signed-off-by: James Morris <james.l.morris@oracle.com>
2016-05-26Yama: fix double-spinlock and user access in atomic contextJann Horn1-6/+63
Commit 8a56038c2aef ("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: 8a56038c2aef ("Yama: consolidate error reporting") Signed-off-by: Jann Horn <jann@thejh.net> Acked-by: Kees Cook <keescook@chromium.org> Signed-off-by: James Morris <james.l.morris@oracle.com>
2016-05-04Yama: use atomic allocations when reportingSasha Levin1-2/+2
Access reporting often happens from atomic contexes. Avoid lockups when allocating memory for command lines. Fixes: 8a56038c2ae ("Yama: consolidate error reporting") Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
2016-04-21Yama: consolidate error reportingKees Cook1-10/+21
Use a common error reporting function for Yama violation reports, and give more detail into the process command lines. Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: James Morris <james.l.morris@oracle.com>
2016-01-20security: let security modules use PTRACE_MODE_* with bitmasksJann Horn1-2/+2
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: Jann Horn <jann@thejh.net> Acked-by: Kees Cook <keescook@chromium.org> Acked-by: Casey Schaufler <casey@schaufler-ca.com> Cc: Oleg Nesterov <oleg@redhat.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: James Morris <james.l.morris@oracle.com> Cc: "Serge E. Hallyn" <serge.hallyn@ubuntu.com> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: "Eric W. Biederman" <ebiederm@xmission.com> Cc: Willy Tarreau <w@1wt.eu> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2015-07-28Yama: remove needless CONFIG_SECURITY_YAMA_STACKEDKees Cook2-30/+11
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: Kees Cook <keescook@chromium.org> Signed-off-by: James Morris <james.l.morris@oracle.com>
2015-05-12LSM: Switch to lists of hooksCasey Schaufler1-35/+15
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: Casey Schaufler <casey@schaufler-ca.com> Acked-by: John Johansen <john.johansen@canonical.com> Acked-by: Kees Cook <keescook@chromium.org> Acked-by: Paul Moore <paul@paul-moore.com> Acked-by: Stephen Smalley <sds@tycho.nsa.gov> Acked-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Signed-off-by: James Morris <james.l.morris@oracle.com>
2015-05-12LSM: Add security module hook list headsCasey Schaufler1-5/+5
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 <casey@schaufler-ca.com> Acked-by: John Johansen <john.johansen@canonical.com> Acked-by: Kees Cook <keescook@chromium.org> Acked-by: Paul Moore <paul@paul-moore.com> Acked-by: Stephen Smalley <sds@tycho.nsa.gov> Acked-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Signed-off-by: James Morris <james.l.morris@oracle.com>
2015-05-12LSM: Split security.hCasey Schaufler1-1/+1
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: Casey Schaufler <casey@schaufler-ca.com> Acked-by: John Johansen <john.johansen@canonical.com> Acked-by: Kees Cook <keescook@chromium.org> Acked-by: Paul Moore <paul@paul-moore.com> Acked-by: Stephen Smalley <sds@tycho.nsa.gov> Acked-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Signed-off-by: James Morris <james.l.morris@oracle.com>
2015-02-27security/yama: Remove unnecessary selects from Kconfig.Stephen Smalley1-2/+0
Yama selects SECURITYFS and SECURITY_PATH, but requires neither. Remove them. Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov> Signed-off-by: Kees Cook <keescook@chromium.org>
2015-02-27Yama: do not modify global sysctl table entryKees Cook1-8/+5
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: Kees Cook <keescook@chromium.org>
2013-03-26yama: Better permission check for ptracemeEric W. Biederman1-3/+1
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: Kees Cook <keescook@chromium.org> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
2012-12-17Merge branch 'for-linus' of ↵Linus Torvalds1-3/+9
git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace Pull user namespace changes from Eric Biederman: "While small this set of changes is very significant with respect to containers in general and user namespaces in particular. The user space interface is now complete. This set of changes adds support for unprivileged users to create user namespaces and as a user namespace root to create other namespaces. The tyranny of supporting suid root preventing unprivileged users from using cool new kernel features is broken. This set of changes completes the work on setns, adding support for the pid, user, mount namespaces. This set of changes includes a bunch of basic pid namespace cleanups/simplifications. Of particular significance is the rework of the pid namespace cleanup so it no longer requires sending out tendrils into all kinds of unexpected cleanup paths for operation. At least one case of broken error handling is fixed by this cleanup. The files under /proc/<pid>/ns/ have been converted from regular files to magic symlinks which prevents incorrect caching by the VFS, ensuring the files always refer to the namespace the process is currently using and ensuring that the ptrace_mayaccess permission checks are always applied. The files under /proc/<pid>/ns/ have been given stable inode numbers so it is now possible to see if different processes share the same namespaces. Through the David Miller's net tree are changes to relax many of the permission checks in the networking stack to allowing the user namespace root to usefully use the networking stack. Similar changes for the mount namespace and the pid namespace are coming through my tree. Two small changes to add user namespace support were commited here adn in David Miller's -net tree so that I could complete the work on the /proc/<pid>/ns/ files in this tree. Work remains to make it safe to build user namespaces and 9p, afs, ceph, cifs, coda, gfs2, ncpfs, nfs, nfsd, ocfs2, and xfs so the Kconfig guard remains in place preventing that user namespaces from being built when any of those filesystems are enabled. Future design work remains to allow root users outside of the initial user namespace to mount more than just /proc and /sys." * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace: (38 commits) proc: Usable inode numbers for the namespace file descriptors. proc: Fix the namespace inode permission checks. proc: Generalize proc inode allocation userns: Allow unprivilged mounts of proc and sysfs userns: For /proc/self/{uid,gid}_map derive the lower userns from the struct file procfs: Print task uids and gids in the userns that opened the proc file userns: Implement unshare of the user namespace userns: Implent proc namespace operations userns: Kill task_user_ns userns: Make create_new_namespaces take a user_ns parameter userns: Allow unprivileged use of setns. userns: Allow unprivileged users to create new namespaces userns: Allow setting a userns mapping to your current uid. userns: Allow chown and setgid preservation userns: Allow unprivileged users to create user namespaces. userns: Ignore suid and sgid on binaries if the uid or gid can not be mapped userns: fix return value on mntns_install() failure vfs: Allow unprivileged manipulation of the mount namespace. vfs: Only support slave subtrees across different user namespaces vfs: Add a user namespace reference from struct mnt_namespace ...
2012-11-20Yama: remove locking from delete pathKees Cook1-7/+42
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 <keescook@chromium.org>
2012-11-20Yama: add RCU to drop read lockingKees Cook1-23/+24
Stop using spinlocks in the read path. Add RCU list to handle the readers. Signed-off-by: Kees Cook <keescook@chromium.org> Reviewed-by: Serge E. Hallyn <serge.hallyn@ubuntu.com> Acked-by: John Johansen <john.johansen@canonical.com>
2012-11-20userns: Kill task_user_nsEric W. Biederman1-3/+9
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: Kees Cook <keescook@chromium.org> Acked-by: Serge Hallyn <serge.hallyn@canonical.com> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
2012-09-28Merge tag 'v3.6-rc7' into nextJames Morris1-8/+2
Linux 3.6-rc7 Requested by David Howells so he can merge his key susbsystem work into my tree with requisite -linus changesets.
2012-09-08Yama: handle 32-bit userspace prctlKees Cook1-1/+1
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: Kees Cook <keescook@chromium.org> Acked-by: John Johansen <john.johansen@canonical.com> Cc: stable@vger.kernel.org Signed-off-by: James Morris <james.l.morris@oracle.com>
2012-09-05security: allow Yama to be unconditionally stackedKees Cook2-4/+18
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: Kees Cook <keescook@chromium.org> Acked-by: Serge E. Hallyn <serge.hallyn@canonical.com> Acked-by: Eric Paris <eparis@redhat.com> Acked-by: John Johansen <john.johansen@canonical.com> Signed-off-by: James Morris <james.l.morris@oracle.com>
2012-08-17Yama: access task_struct->comm directlyKees Cook1-8/+2
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: Oleg Nesterov <oleg@redhat.com> CC: stable@vger.kernel.org Signed-off-by: Kees Cook <keescook@chromium.org> Acked-by: John Johansen <john.johansen@canonical.com> Signed-off-by: James Morris <james.l.morris@oracle.com>
2012-08-10Yama: higher restrictions should block PTRACE_TRACEMEKees Cook1-0/+41
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: Kees Cook <keescook@chromium.org> Cc: stable@vger.kernel.org # 3.5.x and later Signed-off-by: James Morris <james.l.morris@oracle.com>
2012-05-15Yama: replace capable() with ns_capable()Kees Cook1-2/+2
When checking capabilities, the question we want to be asking is "does current() have the capability in the child's namespace?" Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: James Morris <james.l.morris@oracle.com>
2012-04-23Yama: remove an unused variableDan Carpenter1-1/+0
GCC complains that we don't use "one" any more after 389da25f93 "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: Kees Cook <keescook@chromium.org> Signed-off-by: James Morris <james.l.morris@oracle.com>
2012-04-19Yama: add additional ptrace scopesKees Cook1-11/+51
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: Kees Cook <keescook@chromium.org> Signed-off-by: James Morris <james.l.morris@oracle.com>
2012-02-16Yama: add PR_SET_PTRACER_ANYKees Cook1-2/+6
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: Kees Cook <keescook@chromium.org> Signed-off-by: James Morris <jmorris@namei.org>
2012-02-10security: Yama LSMKees Cook3-0/+335
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: Kees Cook <keescook@chromium.org> Acked-by: John Johansen <john.johansen@canonical.com> Signed-off-by: James Morris <jmorris@namei.org>
generated by cgit v1.2.3 (git 2.39.1) at 2024-11-19 10:58:04 +0000