ptrace.2: documentation is incorrect about access checking threads in same thread group

Hi,

There's a bug report: https://bugzilla.kernel.org/show_bug.cgi?id=210655

[[
Under "Ptrace access mode checking", the documentation states:
"1. If the calling thread and the target thread are in the same thread
group, access is always allowed."

This is incorrect. A thread may never attach to another in the same group.

Reference, ptrace_attach()
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/kernel/ptrace.c?h=v5.9.14#n380
]]

I just wanted to make sure that it is a bug in the manual page, and not in the implementation.

Thanks,

Alex

Per my research on the topic, the error is in the manual page.  The behavior of ptrace(2) was intentionally changed to prohibit attaching to a thread in the same group.  Apparently, there were a number of ill-behaved edge cases.

I found this email thread on the subject:
https://lkml.org/lkml/2006/8/31/241

Thank you.
--Ted Estes

Quoted 25 lines · Alejandro Colomar (man-pages)

Hi,

There's a bug report: https://bugzilla.kernel.org/show_bug.cgi?id=210655

[[
Under "Ptrace access mode checking", the documentation states:
   "1. If the calling thread and the target thread are in the same thread group, access is always allowed."

This is incorrect. A thread may never attach to another in the same group.

Reference, ptrace_attach()
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/kernel/ptrace.c?h=v5.9.14#n380

]]

I just wanted to make sure that it is a bug in the manual page, and not in the implementation.

Thanks,

Alex

Hi Ted,

Quoted 7 lines · Ted Estes

Per my research on the topic, the error is in the manual page. The behavior of ptrace(2) was intentionally changed to prohibit attaching to a thread in the same group. Apparently, there were a number of ill-behaved edge cases.

I found this email thread on the subject:
https://lkml.org/lkml/2006/8/31/241

Thank you for all the details and links!
I'll fix the page.

Thanks,

Alex

Quoted 12 lines

Thank you.
--Ted Estes

Quoted 7 lines · Alejandro Colomar (man-pages)

Hi,

There's a bug report: https://bugzilla.kernel.org/show_bug.cgi?id=210655

[[
Under "Ptrace access mode checking", the documentation states:
"1. If the calling thread and the target thread are in the same

Quoted 7 lines

Quoted 7 lines

group, access is always allowed."

This is incorrect. A thread may never attach to another in the same group.

Reference, ptrace_attach()

Quoted 12 lines

Quoted 11 lines

]]

I just wanted to make sure that it is a bug in the manual page, and not in the implementation.

Thanks,

Alex

1) Remove that paragraph, as if that behavior had never existed.

Quoted 2 lines · Alejandro Colomar (man-pages)

1) Remove that paragraph, as if that behavior had never existed.

If it's been 15 years since that paragraph was relevant, I think just removing it is the right thing to do.

Hi,

There's a bug report: https://bugzilla.kernel.org/show_bug.cgi?id=210655

[[
Under "Ptrace access mode checking", the documentation states:
"1. If the calling thread and the target thread are in the same thread
group, access is always allowed."

This is incorrect. A thread may never attach to another in the same group.

Am Tue, Dec 15, 2020 at 06:01:25PM +0100 schrieb Alejandro Colomar (man-pages):

Quoted 10 lines

Hi,

There's a bug report: https://bugzilla.kernel.org/show_bug.cgi?id=210655

[[
Under "Ptrace access mode checking", the documentation states:
"1. If the calling thread and the target thread are in the same thread
group, access is always allowed."

This is incorrect. A thread may never attach to another in the same group.

No, that is correct. ptrace-mode access checks do always short-circuit for tasks in the same thread group:

/* Returns 0 on success, -errno on denial. */
static int __ptrace_may_access(struct task_struct *task, unsigned int mode) {
[...]
/* May we inspect the given task?
* This check is used both for attaching with ptrace
* and for allowing access to sensitive information in /proc. *
* ptrace_attach denies several cases that /proc allows
* because setting up the necessary parent/child relationship
* or halting the specified task is impossible.
*/

/* Don't let security modules deny introspection */ if (same_thread_group(task, current))
return 0;
[...]
}

As the comment explains, you can't actually *attach* to another task in the same thread group; but that's not because of the ptrace-style access check rules, but because specifically *attaching* to another task in the same thread group doesn't work.

Hi Jann,

Quoted 28 lines · Jann Horn

Am Tue, Dec 15, 2020 at 06:01:25PM +0100 schrieb Alejandro Colomar (man-pages):

Quoted 10 lines

Hi,

There's a bug report: https://bugzilla.kernel.org/show_bug.cgi?id=210655

[[
Under "Ptrace access mode checking", the documentation states:
"1. If the calling thread and the target thread are in the same thread
group, access is always allowed."

This is incorrect. A thread may never attach to another in the same group.

No, that is correct. ptrace-mode access checks do always short-circuit for tasks in the same thread group:

/* Returns 0 on success, -errno on denial. */
static int __ptrace_may_access(struct task_struct *task, unsigned int mode) {
[...]
/* May we inspect the given task?
* This check is used both for attaching with ptrace
* and for allowing access to sensitive information in /proc. *
* ptrace_attach denies several cases that /proc allows
* because setting up the necessary parent/child relationship
* or halting the specified task is impossible.
*/

Quoted 5 lines

        /* Don't let security modules deny introspection */
        if (same_thread_group(task, current))
                return 0;

[...]
}

AFAICS, that code always returns non-zero,

at least when called from ptrace_attach().

As you can see below,
__ptrace_may_access() is called some lines after
the code pointed to by the bug report.

static int ptrace_attach(struct task_struct *task, long request,
unsigned long addr,
unsigned long flags)
{
[...]

	if (same_thread_group(task, current))
		goto out;

	/*
	 * Protect exec's credential calculations against our interference;
	 * SUID, SGID and LSM creds get determined differently
	 * under ptrace.
	 */
	retval = -ERESTARTNOINTR;
	if (mutex_lock_interruptible(&task->signal->cred_guard_mutex))
		goto out;

	task_lock(task);
	retval = __ptrace_may_access(task, PTRACE_MODE_ATTACH_REALCREDS);

[...]
}

Thanks,

Alex

Quoted 7 lines

As the comment explains, you can't actually *attach* to another task in the same thread group; but that's not because of the ptrace-style access check rules, but because specifically *attaching* to another task in the same thread group doesn't work.

Quoted 33 lines · Alejandro Colomar (man-pages)

Quoted 31 lines · Jann Horn

Am Tue, Dec 15, 2020 at 06:01:25PM +0100 schrieb Alejandro Colomar (man-pages):

Quoted 8 lines

There's a bug report: https://bugzilla.kernel.org/show_bug.cgi?id=210655

[[
Under "Ptrace access mode checking", the documentation states:
"1. If the calling thread and the target thread are in the same thread
group, access is always allowed."

This is incorrect. A thread may never attach to another in the same group.

No, that is correct. ptrace-mode access checks do always short-circuit for tasks in the same thread group:

/* Returns 0 on success, -errno on denial. */
static int __ptrace_may_access(struct task_struct *task, unsigned int mode) {
[...]
/* May we inspect the given task?
* This check is used both for attaching with ptrace
* and for allowing access to sensitive information in /proc. *
* ptrace_attach denies several cases that /proc allows
* because setting up the necessary parent/child relationship
* or halting the specified task is impossible.
*/

/* Don't let security modules deny introspection */ if (same_thread_group(task, current))
return 0;
[...]
}

Quoted 1 line

AFAICS, that code always returns non-zero,

Sorry, I should have said "that code never returns 0".

Quoted 1 line

at least when called from ptrace_attach().

Quoted 22 lines

As you can see below,
__ptrace_may_access() is called some lines after
the code pointed to by the bug report.

static int ptrace_attach(struct task_struct *task, long request,
unsigned long addr,
unsigned long flags)
{
[...]

      if (same_thread_group(task, current))
              goto out;

      /*
       * Protect exec's credential calculations against our interference;
       * SUID, SGID and LSM creds get determined differently
       * under ptrace.
       */
      retval = -ERESTARTNOINTR;
      if (mutex_lock_interruptible(&task->signal->cred_guard_mutex))
              goto out;

Quoted 4 lines

      task_lock(task);
      retval = __ptrace_may_access(task, PTRACE_MODE_ATTACH_REALCREDS);

[...]
}

Quoted 5 lines

Quoted 5 lines

As the comment explains, you can't actually *attach* to another task in the same thread group; but that's not because of the ptrace-style access check rules, but because specifically *attaching* to another task in the same thread group doesn't work.

Quoted 27 lines · Alejandro Colomar (man-pages)

Quoted 26 lines · Alejandro Colomar (man-pages)

Quoted 25 lines · Jann Horn

Am Tue, Dec 15, 2020 at 06:01:25PM +0100 schrieb Alejandro Colomar (man-pages):

Quoted 8 lines

There's a bug report: https://bugzilla.kernel.org/show_bug.cgi?id=210655

[[
Under "Ptrace access mode checking", the documentation states:
"1. If the calling thread and the target thread are in the same thread
group, access is always allowed."

This is incorrect. A thread may never attach to another in the same group.

No, that is correct. ptrace-mode access checks do always short-circuit for tasks in the same thread group:

/* Returns 0 on success, -errno on denial. */
static int __ptrace_may_access(struct task_struct *task, unsigned int mode) {
[...]
/* May we inspect the given task?
* This check is used both for attaching with ptrace
* and for allowing access to sensitive information in /proc. *
* ptrace_attach denies several cases that /proc allows
* because setting up the necessary parent/child relationship
* or halting the specified task is impossible.
*/

Quoted 9 lines

Quoted 6 lines

Quoted 5 lines

         /* Don't let security modules deny introspection */
         if (same_thread_group(task, current))
                 return 0;

[...]
}

AFAICS, that code always returns non-zero,

Sorry, I should have said "that code never returns 0".

Quoted 1 line

at least when called from ptrace_attach().

Yes.

Quoted 22 lines

Quoted 22 lines

As you can see below,
__ptrace_may_access() is called some lines after
the code pointed to by the bug report.

static int ptrace_attach(struct task_struct *task, long request,
unsigned long addr,
unsigned long flags)
{
[...]

       if (same_thread_group(task, current))
               goto out;

       /*
        * Protect exec's credential calculations against our interference;
        * SUID, SGID and LSM creds get determined differently
        * under ptrace.
        */
       retval = -ERESTARTNOINTR;
       if (mutex_lock_interruptible(&task->signal->cred_guard_mutex))
               goto out;

Quoted 4 lines

Quoted 4 lines

       task_lock(task);
       retval = __ptrace_may_access(task, PTRACE_MODE_ATTACH_REALCREDS);

[...]
}

I said exactly that in my last mail:

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

As the comment explains, you can't actually *attach* to another task in the same thread group; but that's not because of the ptrace-style access check rules, but because specifically *attaching* to another task in the same thread group doesn't work.

As I said, attaching indeed doesn't work. But that's not what "Ptrace access mode checking" means. As the first sentence of that section says:

| Various parts of the kernel-user-space API (not just ptrace()
| operations), require so-called "ptrace access mode" checks,
| whose outcome determines whether an operation is
| permitted (or, in a  few cases,  causes  a "read" operation
| to return sanitized data).

You can find these places by grepping for \bptrace_may_access\b - operations like e.g. the get_robust_list() syscall will always succeed when inspecting other tasks in the caller's thread group thanks to this rule.

Quoted 19 lines · Jann Horn

Quoted 7 lines · Alejandro Colomar (man-pages)

Quoted 6 lines · Alejandro Colomar (man-pages)

Quoted 5 lines · Jann Horn

As the comment explains, you can't actually *attach* to another task in the same thread group; but that's not because of the ptrace-style access check rules, but because specifically *attaching* to another task in the same thread group doesn't work.

As I said, attaching indeed doesn't work. But that's not what "Ptrace access mode checking" means. As the first sentence of that section says:

| Various parts of the kernel-user-space API (not just ptrace()
| operations), require so-called "ptrace access mode" checks,
| whose outcome determines whether an operation is
| permitted (or, in a  few cases,  causes  a "read" operation
| to return sanitized data).

Quoted 4 lines

You can find these places by grepping for \bptrace_may_access\b - operations like e.g. the get_robust_list() syscall will always succeed when inspecting other tasks in the caller's thread group thanks to this rule.

Ah, yes. I missed that back reference while trying to digest that rather meaty man page. A grep on the man page source tree does show a number of references to "ptrace access mode".

That said, the ptrace(2) man page also directly references the ptrace access mode check under both PTRACE_ATTACH and PTACE_SEIZE:

| Permission to perform a PTRACE_ATTACH is governed by a ptrace | access mode PTRACE_MODE_ATTACH_REALCREDS check; see below. As confirmed, the "same thread group" rule does not apply to either of those operations. A re-wording of rule 1 similar to this might help avoid confusion: 1. If the calling thread and the target thread are in the same thread group:
a. For ptrace() called with PTRACE_ATTACH or PTRACE_SEIZE, access is NEVER allowed. b. For all other so-called "ptrace access mode checks", access is ALWAYS allowed. --Ted

Quoted 32 lines · Ted Estes

Quoted 19 lines · Jann Horn

Quoted 7 lines · Alejandro Colomar (man-pages)

Quoted 6 lines · Alejandro Colomar (man-pages)

Quoted 5 lines · Jann Horn

As the comment explains, you can't actually *attach* to another task in the same thread group; but that's not because of the ptrace-style access check rules, but because specifically *attaching* to another task in the same thread group doesn't work.

As I said, attaching indeed doesn't work. But that's not what "Ptrace access mode checking" means. As the first sentence of that section says:

| Various parts of the kernel-user-space API (not just ptrace()
| operations), require so-called "ptrace access mode" checks,
| whose outcome determines whether an operation is
| permitted (or, in a  few cases,  causes  a "read" operation
| to return sanitized data).

Quoted 4 lines

You can find these places by grepping for \bptrace_may_access\b - operations like e.g. the get_robust_list() syscall will always succeed when inspecting other tasks in the caller's thread group thanks to this rule.

Ah, yes. I missed that back reference while trying to digest that rather meaty man page. A grep on the man page source tree does show a number of references to "ptrace access mode".

That said, the ptrace(2) man page also directly references the ptrace access mode check under both PTRACE_ATTACH and PTACE_SEIZE:

Quoted 8 lines

| Permission to perform a PTRACE_ATTACH is governed by a ptrace | access mode PTRACE_MODE_ATTACH_REALCREDS check; see below. As confirmed, the "same thread group" rule does not apply to either of those operations. A re-wording of rule 1 similar to this might help avoid confusion: 1. If the calling thread and the target thread are in the same thread group:
a. For ptrace() called with PTRACE_ATTACH or PTRACE_SEIZE, access is NEVER allowed. b. For all other so-called "ptrace access mode checks", access is ALWAYS allowed. --Ted

Yeah, maybe. OTOH I'm not sure whether it really makes sense to explain this as being part of a security check, or whether it should be explained separately as a restriction on PTRACE_ATTACH and PTRACE_SEIZE (with a note like "(irrelevant for ptrace attachment)" on rule 1). But I don't feel strongly about it either way.

[CC += Thomas, Ingo, Peter, Darren]

Hi Oleg,

Quoted 42 lines · Jann Horn

Quoted 32 lines · Ted Estes

Quoted 19 lines · Jann Horn

Quoted 7 lines · Alejandro Colomar (man-pages)

Quoted 6 lines · Alejandro Colomar (man-pages)

Quoted 5 lines · Jann Horn

As the comment explains, you can't actually *attach* to another task in the same thread group; but that's not because of the ptrace-style access check rules, but because specifically *attaching* to another task in the same thread group doesn't work.

As I said, attaching indeed doesn't work. But that's not what "Ptrace access mode checking" means. As the first sentence of that section says:

| Various parts of the kernel-user-space API (not just ptrace()
| operations), require so-called "ptrace access mode" checks,
| whose outcome determines whether an operation is
| permitted (or, in a  few cases,  causes  a "read" operation
| to return sanitized data).

Quoted 4 lines

You can find these places by grepping for \bptrace_may_access\b - operations like e.g. the get_robust_list() syscall will always succeed when inspecting other tasks in the caller's thread group thanks to this rule.

Ah, yes. I missed that back reference while trying to digest that rather meaty man page. A grep on the man page source tree does show a number of references to "ptrace access mode".

That said, the ptrace(2) man page also directly references the ptrace access mode check under both PTRACE_ATTACH and PTACE_SEIZE:

Quoted 8 lines

| Permission to perform a PTRACE_ATTACH is governed by a ptrace | access mode PTRACE_MODE_ATTACH_REALCREDS check; see below. As confirmed, the "same thread group" rule does not apply to either of those operations. A re-wording of rule 1 similar to this might help avoid confusion: 1. If the calling thread and the target thread are in the same thread group:
a. For ptrace() called with PTRACE_ATTACH or PTRACE_SEIZE, access is NEVER allowed. b. For all other so-called "ptrace access mode checks", access is ALWAYS allowed. --Ted

Quoted 6 lines

Yeah, maybe. OTOH I'm not sure whether it really makes sense to explain this as being part of a security check, or whether it should be explained separately as a restriction on PTRACE_ATTACH and PTRACE_SEIZE (with a note like "(irrelevant for ptrace attachment)" on rule 1). But I don't feel strongly about it either way.

As you are the maintainer for ptrace,
could you confirm the above from Jan?
And maybe suggest what you would do with the manual page.

I'd like to get confirmation that there are still other functions that require "ptrace access mode" other than ptrace() itself, where it's valid that the calling thread and the target thread are in the same group.