Re: [RFC v2] ptrace, pidfd: add pidfd_ptrace syscall
From: Christian Brauner
Date: Tue Apr 28 2020 - 04:21:59 EST
On Mon, Apr 27, 2020 at 09:28:14PM -0700, Linus Torvalds wrote:
> On Mon, Apr 27, 2020 at 9:17 PM Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote:
> >
> > I hate to say this, but Iâm not convinced that asking the gdb folks is
> > the right approach. GDB has an ancient architecture and is
> > *incredibly* buggy. Iâm sure ptrace is somewhere on the pain point
> > list, but I suspect itâs utterly dwarfed by everything else.
>
> You may be right. However, if gdbn isn't going to use it, then I
> seriously don't think it's worth changing much.
>
> It might be worth looking at people who don't use ptrace() for
> debugging, but for "incidental" reasons. IOW sandboxing, tracing,
> things like that.
>
> Maybe those people want things that are simpler and don't actually
> need the kinds of hard serialization that ptrace() wants.
>
> I'd rather add a few really simple things that might not be a full
> complement of operations for a debugger, but exactly because they
> aren't a full debugger, maybe they are things that we can tell are
> obviously secure and simple?
I think the biggest non-anecdotal user of ptrace() besides debuggers
is actually criu (and strace of course). They use it to inject parasite
code (their phrasing not mine) into another task to handle restoring the
parts of a task that can't be restored from the outside. Looking through
their repo they make quite a bit of use of ptrace functionality including
some arch specific bits:
PTRACE_GETREGSET
PTRACE_GETFPREGS
PTRACE_PEEKUSER
PTRACE_POKEUSER
PTRACE_CONT
PTRACE_SETREGSET
PTRACE_GETVFPREGS /* arm/arm64 */
PTRACE_GETVRREGS /* powerpc */
PTRACE_GETVSRREGS /* powerpc */
PTRACE_EVENT_STOP
PTRACE_GETSIGMASK
PTRACE_INTERRUPT
PTRACE_DETACH
PTRACE_GETSIGINFO
PTRACE_SEIZE
PTRACE_SETSIGMASK
PTRACE_SI_EVENT
PTRACE_SYSCALL
PTRACE_SETOPTIONS
PTRACE_ATTACH
PTRACE_O_SUSPEND_SECCOMP
PTRACE_PEEKSIGINFO
PTRACE_SECCOMP_GET_FILTER
PTRACE_SECCOMP_GET_METADATA
So I guess strace and criu would be the ones to go and ask and if they
don't care enough we already need to start squinting for other larg-ish
users. proot comes to mind
https://github.com/proot-me/proot
(From personal experience, most of the time when ptrace is used in a
non-debugger codebase it's either to plug a security hole exploitable
through ptracing the task and the fix is ptracing that very task to
prevent the attacker from ptracing it (where non-dumpability alone
doesn't cut it) or the idea is dropped immediately to not lose the
ability to use a debugger on the program.)
Christian