linux-kernel - Re: [PATCH RFC] Allow introspection to already attached ptracer in __ptrace_may

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 08 Jan 2015 11:40:41 +0100
From:	Stijn Volckaert <Stijn.Volckaert@...s.ugent.be>
To:	Kees Cook <keescook@...omium.org>
CC:	Roland McGrath <roland@...k.frob.com>,
	Oleg Nesterov <oleg@...hat.com>,
	LKML <linux-kernel@...r.kernel.org>,
	linux-security-module <linux-security-module@...r.kernel.org>,
	Stephen Smalley <sds@...ho.nsa.gov>,
	Casey Schaufler <casey@...aufler-ca.com>,
	John Johansen <john.johansen@...onical.com>,
	Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>
Subject: Re: [PATCH RFC] Allow introspection to already attached ptracer in
 __ptrace_may_access

Kees Cook schreef op 6/01/2015 om 0:47:
> Just to make sure I understand this better, "Monitor" is the initial
> process, and [0] and [1] are separate threads within that process? I
> would expect B to have Monitor as its parent after A died, but I must
> be misunderstanding something.
>
> Regardless, your "interesting thing 1" is certainly a side-effect of
> YAMA_SCOPE_RELATIONAL trying to do its job.

I've thought about it some more and there's actually a much easier way to show
what is going on here. Suppose that you have a debugger that forks off its own
tracee and then traces that tracee PLUS any of that tracee's future childs.
At some point you may get:

+----------+                      +----------+
| DEBUGGER | -- FORK + ATTACH --> | TRACEE A |
+----------+                      +----------+
      |                                 |
      |                                 |
      |                                FORK
    ATTACH                              |
      |                                 |
      |                                 V
      |                            +----------+
      +--------------------------> | TRACEE B |
                                   +----------+

Now at this point, if tracee A dies, tracee B will get reparented to the init
process. From that point onwards, the debugger can no longer perform any
operations that go through __ptrace_may_access. These include
process_vm_{read,write}v but also PTRACE_{POKE,PEEK}{TEXT,DATA}. I don't see
how Yama can possibly tell that tracee B and the debugger are still related
at this point so I see no easy fix for this. Patching __ptrace_may_access
might indeed not be a good idea as it is used to check for credentials to
perform a bunch of other non-ptrace operations throughout the kernel.

The possible solutions that I can see right now are:
1) Adding some sort of original_parent field to task_struct, just for the
sake of relationship tracking
2) Changing the credentials check in process_vm_{read,write}v only so that
you don't go all the way into __ptrace_may_access if you're already attached
as a ptracer

-- Stijn

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/