public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: daw@cs.berkeley.edu (David Wagner)
To: linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] x86-64: seccomp: fix 32/64 syscall hole
Date: Fri, 8 May 2009 01:59:03 +0000 (UTC)	[thread overview]
Message-ID: <gu03l7$tb8$1@taverner.cs.berkeley.edu> (raw)
In-Reply-To: 20090507073121.2FAADFC39E@magilla.sf.frob.com

Roland McGrath  wrote:
>> Ptrace has performance and/or reliability problems when used to
>> sandbox threaded applications due to potential race conditions when
>> inspecting system call arguments. We hope that we can avoid this
>> problem with seccomp.
>
>ptrace certainly has performance issues.  I take it the only "reliability
>problems" you are talking about are MT races with modifications to user
>memory that is relevant to a system call.  (Is there something else?)

As of 1999, I believe there were some other issues for using ptrace
securely:

1. I do not know of a good way to reliably ensure that all children of
a traced program will be traced as well.  If you wait for the fork()
call to return, check the pid, and start tracing the child process,
you are subject to race conditions.  (strace's solution is to modify
the code of the traced program to put a trapping instruction immediately
after the call site to fork().  This is a grody hack and I had a hard
time convincing myself that this will be secure in all cases.)

2. ptrace disrupts the process hierarchy and Unix signals.  Because of
the way ptrace overloads signals to deliver tracing events, tracing is
not transparent.  For instance, if the parent and child are both traced,
and the parent waits for a signal from the child, things may no longer
work the same way while being traced.  Working around this requires
non-trivial code.  Complexity is the enemy of security and makes it hard
to gain confidence this doesn't introduce subtle issues.

3. If the tracing application should happen to die unexpectedly
(OOM, anyone?), I believe the traced application continues running,
now without any security checks.

4. I seem to recall that when I looked at this in 1999, if the traced
app makes a syscall that should not be allowed, I couldn't find a good
way to prevent that syscall from executing.  I don't know if current
ptrace has solved this problem.

Disclaimer: I haven't checked whether these all still apply today.

  reply	other threads:[~2009-05-08  2:22 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-28  3:02 [PATCH 0/2] x86-64: 32/64 syscall arch holes Roland McGrath
2009-02-28  3:03 ` [PATCH 1/2] x86-64: syscall-audit: fix 32/64 syscall hole Roland McGrath
2009-02-28  3:04 ` [PATCH 2/2] x86-64: seccomp: " Roland McGrath
2009-02-28  3:36   ` Linus Torvalds
2009-02-28  3:52     ` Linus Torvalds
2009-02-28  4:46       ` Ingo Molnar
2009-02-28  7:25       ` Roland McGrath
2009-02-28  7:31         ` Ingo Molnar
2009-02-28  7:36           ` Roland McGrath
2009-02-28 17:23         ` Linus Torvalds
2009-02-28 17:46           ` [stable] " Greg KH
2009-02-28 17:54             ` Arjan van de Ven
2009-02-28 18:23               ` Greg KH
2009-02-28 20:27                 ` Greg KH
2009-02-28 21:09           ` Benjamin Herrenschmidt
2009-03-02  1:44           ` Roland McGrath
2009-05-06 18:46           ` Markus Gutschke (顧孟勤)
2009-05-06 21:29             ` Ingo Molnar
2009-05-06 21:46               ` Markus Gutschke (顧孟勤)
2009-05-06 21:54                 ` Ingo Molnar
2009-05-06 22:08                   ` Markus Gutschke (顧孟勤)
2009-05-06 22:13                     ` Ingo Molnar
2009-05-06 22:21                       ` Markus Gutschke (顧孟勤)
2009-05-07  4:23                         ` Nicholas Miell
2009-05-07 10:11                           ` Ingo Molnar
2009-05-10  5:37                             ` Pavel Machek
2009-05-08 19:18                     ` Andi Kleen
2009-05-07  7:31                 ` Roland McGrath
2009-05-08  1:59                   ` David Wagner [this message]
2009-05-10  5:36                     ` Pavel Machek
     [not found]                 ` <20090507070312.DCC5EFC39E@magilla.sf.frob.com>
2009-05-07  8:01                   ` Markus Gutschke (顧孟勤)

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='gu03l7$tb8$1@taverner.cs.berkeley.edu' \
    --to=daw@cs.berkeley.edu \
    --cc=daw-news@cs.berkeley.edu \
    --cc=linux-kernel@vger.kernel.org \
    /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