From: Christian Brauner <christian.brauner@ubuntu.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andy Lutomirski <luto@amacapital.net>,
Aleksa Sarai <cyphar@cyphar.com>, Arnd Bergmann <arnd@arndb.de>,
Hagen Paul Pfeifer <hagen@jauu.net>,
"Eric W. Biederman" <ebiederm@xmission.com>,
Jann Horn <jannh@google.com>,
kernel list <linux-kernel@vger.kernel.org>,
Florian Weimer <fweimer@redhat.com>,
Al Viro <viro@zeniv.linux.org.uk>,
Christian Brauner <christian@brauner.io>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
"H. Peter Anvin" <hpa@zytor.com>, Brian Gerst <brgerst@gmail.com>,
Sami Tolvanen <samitolvanen@google.com>,
David Howells <dhowells@redhat.com>,
Andy Lutomirski <luto@kernel.org>,
Oleg Nesterov <oleg@redhat.com>,
Arnaldo Carvalho de Melo <acme@redhat.com>,
Sargun Dhillon <sargun@sargun.me>,
Linux API <linux-api@vger.kernel.org>,
linux-arch <linux-arch@vger.kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: Re: [RFC v2] ptrace, pidfd: add pidfd_ptrace syscall
Date: Tue, 28 Apr 2020 10:21:33 +0200 [thread overview]
Message-ID: <20200428082133.kusyjofgg7w2lchg@wittgenstein> (raw)
In-Reply-To: <CAHk-=whQzOsh9O2uhUO2VETD+hrzjKMpEJpzoUby5QHMcvgPKg@mail.gmail.com>
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@amacapital.net> 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
prev parent reply other threads:[~2020-04-28 8:21 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-26 13:01 [RFC] ptrace, pidfd: add pidfd_ptrace syscall Hagen Paul Pfeifer
2020-04-26 16:34 ` [RFC v2] " Hagen Paul Pfeifer
2020-04-27 8:30 ` Arnd Bergmann
2020-04-27 9:00 ` Hagen Paul Pfeifer
2020-04-27 17:08 ` Christian Brauner
2020-04-27 17:52 ` Jann Horn
2020-04-27 18:18 ` Eric W. Biederman
2020-04-27 18:59 ` Hagen Paul Pfeifer
2020-04-27 20:08 ` Arnd Bergmann
2020-04-27 20:13 ` Christian Brauner
2020-04-28 0:45 ` Aleksa Sarai
2020-04-28 1:36 ` Linus Torvalds
2020-04-28 4:17 ` Andy Lutomirski
2020-04-28 4:28 ` Linus Torvalds
2020-04-28 6:39 ` Hagen Paul Pfeifer
2020-04-28 7:45 ` Christian Brauner
2020-04-28 8:21 ` Christian Brauner [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200428082133.kusyjofgg7w2lchg@wittgenstein \
--to=christian.brauner@ubuntu.com \
--cc=acme@redhat.com \
--cc=arnd@arndb.de \
--cc=bp@alien8.de \
--cc=brgerst@gmail.com \
--cc=christian@brauner.io \
--cc=cyphar@cyphar.com \
--cc=dhowells@redhat.com \
--cc=ebiederm@xmission.com \
--cc=fweimer@redhat.com \
--cc=gregkh@linuxfoundation.org \
--cc=hagen@jauu.net \
--cc=hpa@zytor.com \
--cc=jannh@google.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=luto@kernel.org \
--cc=mingo@redhat.com \
--cc=oleg@redhat.com \
--cc=samitolvanen@google.com \
--cc=sargun@sargun.me \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).