2019-06-04 08:11:33 +00:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-only
|
2011-12-21 20:17:04 +00:00
|
|
|
/*
|
|
|
|
* Yama Linux Security Module
|
|
|
|
*
|
|
|
|
* Author: Kees Cook <keescook@chromium.org>
|
|
|
|
*
|
|
|
|
* Copyright (C) 2010 Canonical, Ltd.
|
|
|
|
* Copyright (C) 2011 The Chromium OS Authors.
|
|
|
|
*/
|
|
|
|
|
2015-05-02 22:10:46 +00:00
|
|
|
#include <linux/lsm_hooks.h>
|
2011-12-21 20:17:04 +00:00
|
|
|
#include <linux/sysctl.h>
|
|
|
|
#include <linux/ptrace.h>
|
|
|
|
#include <linux/prctl.h>
|
|
|
|
#include <linux/ratelimit.h>
|
2012-11-19 23:21:26 +00:00
|
|
|
#include <linux/workqueue.h>
|
2016-04-20 22:46:26 +00:00
|
|
|
#include <linux/string_helpers.h>
|
Yama: fix double-spinlock and user access in atomic context
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-22 04:01:34 +00:00
|
|
|
#include <linux/task_work.h>
|
|
|
|
#include <linux/sched.h>
|
|
|
|
#include <linux/spinlock.h>
|
2023-09-12 20:56:46 +00:00
|
|
|
#include <uapi/linux/lsm.h>
|
2011-12-21 20:17:04 +00:00
|
|
|
|
2012-04-16 18:56:45 +00:00
|
|
|
#define YAMA_SCOPE_DISABLED 0
|
|
|
|
#define YAMA_SCOPE_RELATIONAL 1
|
|
|
|
#define YAMA_SCOPE_CAPABILITY 2
|
|
|
|
#define YAMA_SCOPE_NO_ATTACH 3
|
|
|
|
|
|
|
|
static int ptrace_scope = YAMA_SCOPE_RELATIONAL;
|
2011-12-21 20:17:04 +00:00
|
|
|
|
|
|
|
/* describe a ptrace relationship for potential exception */
|
|
|
|
struct ptrace_relation {
|
|
|
|
struct task_struct *tracer;
|
|
|
|
struct task_struct *tracee;
|
2012-11-19 23:21:26 +00:00
|
|
|
bool invalid;
|
2011-12-21 20:17:04 +00:00
|
|
|
struct list_head node;
|
2012-10-18 21:53:58 +00:00
|
|
|
struct rcu_head rcu;
|
2011-12-21 20:17:04 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
static LIST_HEAD(ptracer_relations);
|
|
|
|
static DEFINE_SPINLOCK(ptracer_relations_lock);
|
|
|
|
|
2012-11-19 23:21:26 +00:00
|
|
|
static void yama_relation_cleanup(struct work_struct *work);
|
|
|
|
static DECLARE_WORK(yama_relation_work, yama_relation_cleanup);
|
|
|
|
|
Yama: fix double-spinlock and user access in atomic context
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-22 04:01:34 +00:00
|
|
|
struct access_report_info {
|
|
|
|
struct callback_head work;
|
|
|
|
const char *access;
|
|
|
|
struct task_struct *target;
|
|
|
|
struct task_struct *agent;
|
|
|
|
};
|
|
|
|
|
|
|
|
static void __report_access(struct callback_head *work)
|
2016-04-20 22:46:26 +00:00
|
|
|
{
|
Yama: fix double-spinlock and user access in atomic context
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-22 04:01:34 +00:00
|
|
|
struct access_report_info *info =
|
|
|
|
container_of(work, struct access_report_info, work);
|
2016-04-20 22:46:26 +00:00
|
|
|
char *target_cmd, *agent_cmd;
|
|
|
|
|
Yama: fix double-spinlock and user access in atomic context
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-22 04:01:34 +00:00
|
|
|
target_cmd = kstrdup_quotable_cmdline(info->target, GFP_KERNEL);
|
|
|
|
agent_cmd = kstrdup_quotable_cmdline(info->agent, GFP_KERNEL);
|
2016-04-20 22:46:26 +00:00
|
|
|
|
|
|
|
pr_notice_ratelimited(
|
|
|
|
"ptrace %s of \"%s\"[%d] was attempted by \"%s\"[%d]\n",
|
Yama: fix double-spinlock and user access in atomic context
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-22 04:01:34 +00:00
|
|
|
info->access, target_cmd, info->target->pid, agent_cmd,
|
|
|
|
info->agent->pid);
|
2016-04-20 22:46:26 +00:00
|
|
|
|
|
|
|
kfree(agent_cmd);
|
|
|
|
kfree(target_cmd);
|
Yama: fix double-spinlock and user access in atomic context
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-22 04:01:34 +00:00
|
|
|
|
|
|
|
put_task_struct(info->agent);
|
|
|
|
put_task_struct(info->target);
|
|
|
|
kfree(info);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* defers execution because cmdline access can sleep */
|
|
|
|
static void report_access(const char *access, struct task_struct *target,
|
|
|
|
struct task_struct *agent)
|
|
|
|
{
|
|
|
|
struct access_report_info *info;
|
|
|
|
char agent_comm[sizeof(agent->comm)];
|
|
|
|
|
|
|
|
assert_spin_locked(&target->alloc_lock); /* for target->comm */
|
|
|
|
|
|
|
|
if (current->flags & PF_KTHREAD) {
|
|
|
|
/* I don't think kthreads call task_work_run() before exiting.
|
|
|
|
* Imagine angry ranting about procfs here.
|
|
|
|
*/
|
|
|
|
pr_notice_ratelimited(
|
|
|
|
"ptrace %s of \"%s\"[%d] was attempted by \"%s\"[%d]\n",
|
|
|
|
access, target->comm, target->pid,
|
|
|
|
get_task_comm(agent_comm, agent), agent->pid);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
info = kmalloc(sizeof(*info), GFP_ATOMIC);
|
|
|
|
if (!info)
|
|
|
|
return;
|
|
|
|
init_task_work(&info->work, __report_access);
|
|
|
|
get_task_struct(target);
|
|
|
|
get_task_struct(agent);
|
|
|
|
info->access = access;
|
|
|
|
info->target = target;
|
|
|
|
info->agent = agent;
|
task_work: cleanup notification modes
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: e91b48162332 ("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>
2020-10-16 15:02:26 +00:00
|
|
|
if (task_work_add(current, &info->work, TWA_RESUME) == 0)
|
Yama: fix double-spinlock and user access in atomic context
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-22 04:01:34 +00:00
|
|
|
return; /* success */
|
|
|
|
|
|
|
|
WARN(1, "report_access called from exiting task");
|
|
|
|
put_task_struct(target);
|
|
|
|
put_task_struct(agent);
|
|
|
|
kfree(info);
|
2016-04-20 22:46:26 +00:00
|
|
|
}
|
|
|
|
|
2012-11-19 23:21:26 +00:00
|
|
|
/**
|
|
|
|
* yama_relation_cleanup - remove invalid entries from the relation list
|
2024-03-15 12:54:10 +00:00
|
|
|
* @work: unused
|
2012-11-19 23:21:26 +00:00
|
|
|
*
|
|
|
|
*/
|
|
|
|
static void yama_relation_cleanup(struct work_struct *work)
|
|
|
|
{
|
|
|
|
struct ptrace_relation *relation;
|
|
|
|
|
|
|
|
spin_lock(&ptracer_relations_lock);
|
|
|
|
rcu_read_lock();
|
|
|
|
list_for_each_entry_rcu(relation, &ptracer_relations, node) {
|
|
|
|
if (relation->invalid) {
|
|
|
|
list_del_rcu(&relation->node);
|
|
|
|
kfree_rcu(relation, rcu);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
rcu_read_unlock();
|
|
|
|
spin_unlock(&ptracer_relations_lock);
|
|
|
|
}
|
|
|
|
|
2011-12-21 20:17:04 +00:00
|
|
|
/**
|
|
|
|
* yama_ptracer_add - add/replace an exception for this tracer/tracee pair
|
|
|
|
* @tracer: the task_struct of the process doing the ptrace
|
|
|
|
* @tracee: the task_struct of the process to be ptraced
|
|
|
|
*
|
|
|
|
* Each tracee can have, at most, one tracer registered. Each time this
|
|
|
|
* is called, the prior registered tracer will be replaced for the tracee.
|
|
|
|
*
|
|
|
|
* Returns 0 if relationship was added, -ve on error.
|
|
|
|
*/
|
|
|
|
static int yama_ptracer_add(struct task_struct *tracer,
|
|
|
|
struct task_struct *tracee)
|
|
|
|
{
|
2012-10-18 21:53:58 +00:00
|
|
|
struct ptrace_relation *relation, *added;
|
2011-12-21 20:17:04 +00:00
|
|
|
|
|
|
|
added = kmalloc(sizeof(*added), GFP_KERNEL);
|
|
|
|
if (!added)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
2012-10-18 21:53:58 +00:00
|
|
|
added->tracee = tracee;
|
|
|
|
added->tracer = tracer;
|
2012-11-19 23:21:26 +00:00
|
|
|
added->invalid = false;
|
2012-10-18 21:53:58 +00:00
|
|
|
|
2012-11-19 23:21:26 +00:00
|
|
|
spin_lock(&ptracer_relations_lock);
|
2012-10-18 21:53:58 +00:00
|
|
|
rcu_read_lock();
|
|
|
|
list_for_each_entry_rcu(relation, &ptracer_relations, node) {
|
2012-11-19 23:21:26 +00:00
|
|
|
if (relation->invalid)
|
|
|
|
continue;
|
2012-10-18 21:53:58 +00:00
|
|
|
if (relation->tracee == tracee) {
|
|
|
|
list_replace_rcu(&relation->node, &added->node);
|
|
|
|
kfree_rcu(relation, rcu);
|
|
|
|
goto out;
|
2011-12-21 20:17:04 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2012-10-18 21:53:58 +00:00
|
|
|
list_add_rcu(&added->node, &ptracer_relations);
|
2011-12-21 20:17:04 +00:00
|
|
|
|
2012-10-18 21:53:58 +00:00
|
|
|
out:
|
|
|
|
rcu_read_unlock();
|
2012-11-19 23:21:26 +00:00
|
|
|
spin_unlock(&ptracer_relations_lock);
|
2012-10-18 21:53:58 +00:00
|
|
|
return 0;
|
2011-12-21 20:17:04 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* yama_ptracer_del - remove exceptions related to the given tasks
|
|
|
|
* @tracer: remove any relation where tracer task matches
|
|
|
|
* @tracee: remove any relation where tracee task matches
|
|
|
|
*/
|
|
|
|
static void yama_ptracer_del(struct task_struct *tracer,
|
|
|
|
struct task_struct *tracee)
|
|
|
|
{
|
2012-10-18 21:53:58 +00:00
|
|
|
struct ptrace_relation *relation;
|
2012-11-19 23:21:26 +00:00
|
|
|
bool marked = false;
|
2011-12-21 20:17:04 +00:00
|
|
|
|
2012-10-18 21:53:58 +00:00
|
|
|
rcu_read_lock();
|
|
|
|
list_for_each_entry_rcu(relation, &ptracer_relations, node) {
|
2012-11-19 23:21:26 +00:00
|
|
|
if (relation->invalid)
|
|
|
|
continue;
|
2011-12-21 20:17:04 +00:00
|
|
|
if (relation->tracee == tracee ||
|
2012-02-15 00:48:09 +00:00
|
|
|
(tracer && relation->tracer == tracer)) {
|
2012-11-19 23:21:26 +00:00
|
|
|
relation->invalid = true;
|
|
|
|
marked = true;
|
2011-12-21 20:17:04 +00:00
|
|
|
}
|
2012-10-18 21:53:58 +00:00
|
|
|
}
|
|
|
|
rcu_read_unlock();
|
2012-11-19 23:21:26 +00:00
|
|
|
|
|
|
|
if (marked)
|
|
|
|
schedule_work(&yama_relation_work);
|
2011-12-21 20:17:04 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* yama_task_free - check for task_pid to remove from exception list
|
|
|
|
* @task: task being removed
|
|
|
|
*/
|
2019-03-28 00:21:42 +00:00
|
|
|
static void yama_task_free(struct task_struct *task)
|
2011-12-21 20:17:04 +00:00
|
|
|
{
|
|
|
|
yama_ptracer_del(task, task);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* yama_task_prctl - check for Yama-specific prctl operations
|
|
|
|
* @option: operation
|
|
|
|
* @arg2: argument
|
|
|
|
* @arg3: argument
|
|
|
|
* @arg4: argument
|
|
|
|
* @arg5: argument
|
|
|
|
*
|
|
|
|
* Return 0 on success, -ve on error. -ENOSYS is returned when Yama
|
|
|
|
* does not handle the given option.
|
|
|
|
*/
|
2019-03-28 00:21:42 +00:00
|
|
|
static int yama_task_prctl(int option, unsigned long arg2, unsigned long arg3,
|
2011-12-21 20:17:04 +00:00
|
|
|
unsigned long arg4, unsigned long arg5)
|
|
|
|
{
|
2015-05-02 22:11:42 +00:00
|
|
|
int rc = -ENOSYS;
|
2011-12-21 20:17:04 +00:00
|
|
|
struct task_struct *myself = current;
|
|
|
|
|
|
|
|
switch (option) {
|
|
|
|
case PR_SET_PTRACER:
|
|
|
|
/* Since a thread can call prctl(), find the group leader
|
|
|
|
* before calling _add() or _del() on it, since we want
|
|
|
|
* process-level granularity of control. The tracer group
|
|
|
|
* leader checking is handled later when walking the ancestry
|
|
|
|
* at the time of PTRACE_ATTACH check.
|
|
|
|
*/
|
|
|
|
rcu_read_lock();
|
|
|
|
if (!thread_group_leader(myself))
|
|
|
|
myself = rcu_dereference(myself->group_leader);
|
|
|
|
get_task_struct(myself);
|
|
|
|
rcu_read_unlock();
|
|
|
|
|
|
|
|
if (arg2 == 0) {
|
|
|
|
yama_ptracer_del(NULL, myself);
|
|
|
|
rc = 0;
|
2012-08-27 18:38:13 +00:00
|
|
|
} else if (arg2 == PR_SET_PTRACER_ANY || (int)arg2 == -1) {
|
2012-02-15 00:48:09 +00:00
|
|
|
rc = yama_ptracer_add(NULL, myself);
|
2011-12-21 20:17:04 +00:00
|
|
|
} else {
|
|
|
|
struct task_struct *tracer;
|
|
|
|
|
2018-02-06 23:40:17 +00:00
|
|
|
tracer = find_get_task_by_vpid(arg2);
|
|
|
|
if (!tracer) {
|
2011-12-21 20:17:04 +00:00
|
|
|
rc = -EINVAL;
|
2018-02-06 23:40:17 +00:00
|
|
|
} else {
|
2011-12-21 20:17:04 +00:00
|
|
|
rc = yama_ptracer_add(tracer, myself);
|
|
|
|
put_task_struct(tracer);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
put_task_struct(myself);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
return rc;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* task_is_descendant - walk up a process family tree looking for a match
|
|
|
|
* @parent: the process to compare against while walking up from child
|
|
|
|
* @child: the process to start from while looking upwards for parent
|
|
|
|
*
|
|
|
|
* Returns 1 if child is a descendant of parent, 0 if not.
|
|
|
|
*/
|
|
|
|
static int task_is_descendant(struct task_struct *parent,
|
|
|
|
struct task_struct *child)
|
|
|
|
{
|
|
|
|
int rc = 0;
|
|
|
|
struct task_struct *walker = child;
|
|
|
|
|
|
|
|
if (!parent || !child)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
rcu_read_lock();
|
|
|
|
if (!thread_group_leader(parent))
|
|
|
|
parent = rcu_dereference(parent->group_leader);
|
|
|
|
while (walker->pid > 0) {
|
|
|
|
if (!thread_group_leader(walker))
|
|
|
|
walker = rcu_dereference(walker->group_leader);
|
|
|
|
if (walker == parent) {
|
|
|
|
rc = 1;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
walker = rcu_dereference(walker->real_parent);
|
|
|
|
}
|
|
|
|
rcu_read_unlock();
|
|
|
|
|
|
|
|
return rc;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* ptracer_exception_found - tracer registered as exception for this tracee
|
|
|
|
* @tracer: the task_struct of the process attempting ptrace
|
|
|
|
* @tracee: the task_struct of the process to be ptraced
|
|
|
|
*
|
2016-12-02 23:49:43 +00:00
|
|
|
* Returns 1 if tracer has a ptracer exception ancestor for tracee.
|
2011-12-21 20:17:04 +00:00
|
|
|
*/
|
|
|
|
static int ptracer_exception_found(struct task_struct *tracer,
|
|
|
|
struct task_struct *tracee)
|
|
|
|
{
|
|
|
|
int rc = 0;
|
|
|
|
struct ptrace_relation *relation;
|
|
|
|
struct task_struct *parent = NULL;
|
2012-02-15 00:48:09 +00:00
|
|
|
bool found = false;
|
2011-12-21 20:17:04 +00:00
|
|
|
|
|
|
|
rcu_read_lock();
|
2016-12-02 23:49:43 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* If there's already an active tracing relationship, then make an
|
|
|
|
* exception for the sake of other accesses, like process_vm_rw().
|
|
|
|
*/
|
|
|
|
parent = ptrace_parent(tracee);
|
|
|
|
if (parent != NULL && same_thread_group(parent, tracer)) {
|
|
|
|
rc = 1;
|
|
|
|
goto unlock;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Look for a PR_SET_PTRACER relationship. */
|
2011-12-21 20:17:04 +00:00
|
|
|
if (!thread_group_leader(tracee))
|
|
|
|
tracee = rcu_dereference(tracee->group_leader);
|
2012-11-19 23:21:26 +00:00
|
|
|
list_for_each_entry_rcu(relation, &ptracer_relations, node) {
|
|
|
|
if (relation->invalid)
|
|
|
|
continue;
|
2011-12-21 20:17:04 +00:00
|
|
|
if (relation->tracee == tracee) {
|
|
|
|
parent = relation->tracer;
|
2012-02-15 00:48:09 +00:00
|
|
|
found = true;
|
2011-12-21 20:17:04 +00:00
|
|
|
break;
|
|
|
|
}
|
2012-11-19 23:21:26 +00:00
|
|
|
}
|
2011-12-21 20:17:04 +00:00
|
|
|
|
2012-02-15 00:48:09 +00:00
|
|
|
if (found && (parent == NULL || task_is_descendant(parent, tracer)))
|
2011-12-21 20:17:04 +00:00
|
|
|
rc = 1;
|
2016-12-02 23:49:43 +00:00
|
|
|
|
|
|
|
unlock:
|
2011-12-21 20:17:04 +00:00
|
|
|
rcu_read_unlock();
|
|
|
|
|
|
|
|
return rc;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* yama_ptrace_access_check - validate PTRACE_ATTACH calls
|
|
|
|
* @child: task that current task is attempting to ptrace
|
|
|
|
* @mode: ptrace attach mode
|
|
|
|
*
|
|
|
|
* Returns 0 if following the ptrace is allowed, -ve on error.
|
|
|
|
*/
|
2015-05-02 22:11:42 +00:00
|
|
|
static int yama_ptrace_access_check(struct task_struct *child,
|
2011-12-21 20:17:04 +00:00
|
|
|
unsigned int mode)
|
|
|
|
{
|
2015-05-02 22:11:42 +00:00
|
|
|
int rc = 0;
|
2011-12-21 20:17:04 +00:00
|
|
|
|
|
|
|
/* require ptrace target be a child of ptracer on attach */
|
2016-01-20 23:00:01 +00:00
|
|
|
if (mode & PTRACE_MODE_ATTACH) {
|
2012-04-16 18:56:45 +00:00
|
|
|
switch (ptrace_scope) {
|
|
|
|
case YAMA_SCOPE_DISABLED:
|
|
|
|
/* No additional restrictions. */
|
|
|
|
break;
|
|
|
|
case YAMA_SCOPE_RELATIONAL:
|
2012-07-26 12:05:21 +00:00
|
|
|
rcu_read_lock();
|
2019-01-16 18:31:09 +00:00
|
|
|
if (!pid_alive(child))
|
|
|
|
rc = -EPERM;
|
|
|
|
if (!rc && !task_is_descendant(current, child) &&
|
2012-04-16 18:56:45 +00:00
|
|
|
!ptracer_exception_found(current, child) &&
|
2012-07-26 12:05:21 +00:00
|
|
|
!ns_capable(__task_cred(child)->user_ns, CAP_SYS_PTRACE))
|
2012-04-16 18:56:45 +00:00
|
|
|
rc = -EPERM;
|
2012-07-26 12:05:21 +00:00
|
|
|
rcu_read_unlock();
|
2012-04-16 18:56:45 +00:00
|
|
|
break;
|
|
|
|
case YAMA_SCOPE_CAPABILITY:
|
2012-07-26 12:05:21 +00:00
|
|
|
rcu_read_lock();
|
|
|
|
if (!ns_capable(__task_cred(child)->user_ns, CAP_SYS_PTRACE))
|
2012-04-16 18:56:45 +00:00
|
|
|
rc = -EPERM;
|
2012-07-26 12:05:21 +00:00
|
|
|
rcu_read_unlock();
|
2012-04-16 18:56:45 +00:00
|
|
|
break;
|
|
|
|
case YAMA_SCOPE_NO_ATTACH:
|
|
|
|
default:
|
|
|
|
rc = -EPERM;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
2011-12-21 20:17:04 +00:00
|
|
|
|
2016-04-20 22:46:26 +00:00
|
|
|
if (rc && (mode & PTRACE_MODE_NOAUDIT) == 0)
|
|
|
|
report_access("attach", child, current);
|
2011-12-21 20:17:04 +00:00
|
|
|
|
|
|
|
return rc;
|
|
|
|
}
|
|
|
|
|
2012-08-10 02:01:26 +00:00
|
|
|
/**
|
|
|
|
* yama_ptrace_traceme - validate PTRACE_TRACEME calls
|
|
|
|
* @parent: task that will become the ptracer of the current task
|
|
|
|
*
|
|
|
|
* Returns 0 if following the ptrace is allowed, -ve on error.
|
|
|
|
*/
|
2019-03-28 00:21:42 +00:00
|
|
|
static int yama_ptrace_traceme(struct task_struct *parent)
|
2012-08-10 02:01:26 +00:00
|
|
|
{
|
2015-05-02 22:11:42 +00:00
|
|
|
int rc = 0;
|
2012-08-10 02:01:26 +00:00
|
|
|
|
|
|
|
/* Only disallow PTRACE_TRACEME on more aggressive settings. */
|
|
|
|
switch (ptrace_scope) {
|
|
|
|
case YAMA_SCOPE_CAPABILITY:
|
2013-03-21 09:30:41 +00:00
|
|
|
if (!has_ns_capability(parent, current_user_ns(), CAP_SYS_PTRACE))
|
2012-08-10 02:01:26 +00:00
|
|
|
rc = -EPERM;
|
|
|
|
break;
|
|
|
|
case YAMA_SCOPE_NO_ATTACH:
|
|
|
|
rc = -EPERM;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
Yama: fix double-spinlock and user access in atomic context
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-22 04:01:34 +00:00
|
|
|
if (rc) {
|
|
|
|
task_lock(current);
|
2016-04-20 22:46:26 +00:00
|
|
|
report_access("traceme", current, parent);
|
Yama: fix double-spinlock and user access in atomic context
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-22 04:01:34 +00:00
|
|
|
task_unlock(current);
|
|
|
|
}
|
2012-08-10 02:01:26 +00:00
|
|
|
|
|
|
|
return rc;
|
|
|
|
}
|
|
|
|
|
2023-11-10 17:09:33 +00:00
|
|
|
static const struct lsm_id yama_lsmid = {
|
2023-09-12 20:56:46 +00:00
|
|
|
.name = "yama",
|
|
|
|
.id = LSM_ID_YAMA,
|
|
|
|
};
|
|
|
|
|
selinux: remove the runtime disable functionality
After working with the larger SELinux-based distros for several
years, we're finally at a place where we can disable the SELinux
runtime disable functionality. The existing kernel deprecation
notice explains the functionality and why we want to remove it:
The selinuxfs "disable" node allows SELinux to be disabled at
runtime prior to a policy being loaded into the kernel. If
disabled via this mechanism, SELinux will remain disabled until
the system is rebooted.
The preferred method of disabling SELinux is via the "selinux=0"
boot parameter, but the selinuxfs "disable" node was created to
make it easier for systems with primitive bootloaders that did not
allow for easy modification of the kernel command line.
Unfortunately, allowing for SELinux to be disabled at runtime makes
it difficult to secure the kernel's LSM hooks using the
"__ro_after_init" feature.
It is that last sentence, mentioning the '__ro_after_init' hardening,
which is the real motivation for this change, and if you look at the
diffstat you'll see that the impact of this patch reaches across all
the different LSMs, helping prevent tampering at the LSM hook level.
From a SELinux perspective, it is important to note that if you
continue to disable SELinux via "/etc/selinux/config" it may appear
that SELinux is disabled, but it is simply in an uninitialized state.
If you load a policy with `load_policy -i`, you will see SELinux
come alive just as if you had loaded the policy during early-boot.
It is also worth noting that the "/sys/fs/selinux/disable" file is
always writable now, regardless of the Kconfig settings, but writing
to the file has no effect on the system, other than to display an
error on the console if a non-zero/true value is written.
Finally, in the several years where we have been working on
deprecating this functionality, there has only been one instance of
someone mentioning any user visible breakage. In this particular
case it was an individual's kernel test system, and the workaround
documented in the deprecation notice ("selinux=0" on the kernel
command line) resolved the issue without problem.
Acked-by: Casey Schaufler <casey@schaufler-ca.com>
Signed-off-by: Paul Moore <paul@paul-moore.com>
2023-03-17 16:43:07 +00:00
|
|
|
static struct security_hook_list yama_hooks[] __ro_after_init = {
|
2015-05-02 22:11:36 +00:00
|
|
|
LSM_HOOK_INIT(ptrace_access_check, yama_ptrace_access_check),
|
|
|
|
LSM_HOOK_INIT(ptrace_traceme, yama_ptrace_traceme),
|
|
|
|
LSM_HOOK_INIT(task_prctl, yama_task_prctl),
|
|
|
|
LSM_HOOK_INIT(task_free, yama_task_free),
|
2011-12-21 20:17:04 +00:00
|
|
|
};
|
2015-05-02 22:11:42 +00:00
|
|
|
|
2011-12-21 20:17:04 +00:00
|
|
|
#ifdef CONFIG_SYSCTL
|
sysctl: treewide: constify the ctl_table argument of proc_handlers
const qualify the struct ctl_table argument in the proc_handler function
signatures. This is a prerequisite to moving the static ctl_table
structs into .rodata data which will ensure that proc_handler function
pointers cannot be modified.
This patch has been generated by the following coccinelle script:
```
virtual patch
@r1@
identifier ctl, write, buffer, lenp, ppos;
identifier func !~ "appldata_(timer|interval)_handler|sched_(rt|rr)_handler|rds_tcp_skbuf_handler|proc_sctp_do_(hmac_alg|rto_min|rto_max|udp_port|alpha_beta|auth|probe_interval)";
@@
int func(
- struct ctl_table *ctl
+ const struct ctl_table *ctl
,int write, void *buffer, size_t *lenp, loff_t *ppos);
@r2@
identifier func, ctl, write, buffer, lenp, ppos;
@@
int func(
- struct ctl_table *ctl
+ const struct ctl_table *ctl
,int write, void *buffer, size_t *lenp, loff_t *ppos)
{ ... }
@r3@
identifier func;
@@
int func(
- struct ctl_table *
+ const struct ctl_table *
,int , void *, size_t *, loff_t *);
@r4@
identifier func, ctl;
@@
int func(
- struct ctl_table *ctl
+ const struct ctl_table *ctl
,int , void *, size_t *, loff_t *);
@r5@
identifier func, write, buffer, lenp, ppos;
@@
int func(
- struct ctl_table *
+ const struct ctl_table *
,int write, void *buffer, size_t *lenp, loff_t *ppos);
```
* Code formatting was adjusted in xfs_sysctl.c to comply with code
conventions. The xfs_stats_clear_proc_handler,
xfs_panic_mask_proc_handler and xfs_deprecated_dointvec_minmax where
adjusted.
* The ctl_table argument in proc_watchdog_common was const qualified.
This is called from a proc_handler itself and is calling back into
another proc_handler, making it necessary to change it as part of the
proc_handler migration.
Co-developed-by: Thomas Weißschuh <linux@weissschuh.net>
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Co-developed-by: Joel Granados <j.granados@samsung.com>
Signed-off-by: Joel Granados <j.granados@samsung.com>
2024-07-24 18:59:29 +00:00
|
|
|
static int yama_dointvec_minmax(const struct ctl_table *table, int write,
|
2020-04-24 06:43:38 +00:00
|
|
|
void *buffer, size_t *lenp, loff_t *ppos)
|
2012-04-16 18:56:45 +00:00
|
|
|
{
|
2013-02-27 16:37:56 +00:00
|
|
|
struct ctl_table table_copy;
|
2012-04-16 18:56:45 +00:00
|
|
|
|
|
|
|
if (write && !capable(CAP_SYS_PTRACE))
|
|
|
|
return -EPERM;
|
|
|
|
|
|
|
|
/* Lock the max value if it ever gets set. */
|
2013-02-27 16:37:56 +00:00
|
|
|
table_copy = *table;
|
|
|
|
if (*(int *)table_copy.data == *(int *)table_copy.extra2)
|
|
|
|
table_copy.extra1 = table_copy.extra2;
|
2012-04-16 18:56:45 +00:00
|
|
|
|
2013-02-27 16:37:56 +00:00
|
|
|
return proc_dointvec_minmax(&table_copy, write, buffer, lenp, ppos);
|
2012-04-16 18:56:45 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static int max_scope = YAMA_SCOPE_NO_ATTACH;
|
2011-12-21 20:17:04 +00:00
|
|
|
|
|
|
|
static struct ctl_table yama_sysctl_table[] = {
|
|
|
|
{
|
|
|
|
.procname = "ptrace_scope",
|
|
|
|
.data = &ptrace_scope,
|
|
|
|
.maxlen = sizeof(int),
|
|
|
|
.mode = 0644,
|
2012-04-16 18:56:45 +00:00
|
|
|
.proc_handler = yama_dointvec_minmax,
|
proc/sysctl: add shared variables for range check
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>
2019-07-18 22:58:50 +00:00
|
|
|
.extra1 = SYSCTL_ZERO,
|
2012-04-16 18:56:45 +00:00
|
|
|
.extra2 = &max_scope,
|
2011-12-21 20:17:04 +00:00
|
|
|
},
|
|
|
|
};
|
2015-07-24 01:02:48 +00:00
|
|
|
static void __init yama_init_sysctl(void)
|
2011-12-21 20:17:04 +00:00
|
|
|
{
|
2023-03-02 20:28:21 +00:00
|
|
|
if (!register_sysctl("kernel/yama", yama_sysctl_table))
|
2011-12-21 20:17:04 +00:00
|
|
|
panic("Yama: sysctl registration failed.\n");
|
|
|
|
}
|
2015-07-24 01:02:48 +00:00
|
|
|
#else
|
|
|
|
static inline void yama_init_sysctl(void) { }
|
|
|
|
#endif /* CONFIG_SYSCTL */
|
2011-12-21 20:17:04 +00:00
|
|
|
|
2018-09-14 22:37:20 +00:00
|
|
|
static int __init yama_init(void)
|
2015-07-24 01:02:48 +00:00
|
|
|
{
|
|
|
|
pr_info("Yama: becoming mindful.\n");
|
2023-09-12 20:56:46 +00:00
|
|
|
security_add_hooks(yama_hooks, ARRAY_SIZE(yama_hooks), &yama_lsmid);
|
2015-07-24 01:02:48 +00:00
|
|
|
yama_init_sysctl();
|
2018-09-14 22:37:20 +00:00
|
|
|
return 0;
|
2015-07-24 01:02:48 +00:00
|
|
|
}
|
2018-09-14 22:37:20 +00:00
|
|
|
|
|
|
|
DEFINE_LSM(yama) = {
|
|
|
|
.name = "yama",
|
|
|
|
.init = yama_init,
|
|
|
|
};
|