lkml.org 
[lkml]   [2005]   [Jan]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: seccomp for 2.6.11-rc1-bk8
    On Fri, Jan 21, 2005 at 01:47:01PM +0100, Ingo Molnar wrote:
    >
    > * Ingo Molnar <mingo@elte.hu> wrote:
    >
    > > > This is the seccomp patch ported to 2.6.11-rc1-bk8, that I need for
    > > > Cpushare (until trusted computing will hit the hardware market).
    > > > [...]
    > >
    > > why do you need any kernel code for this? This seems to be a limited
    > > ptrace implementation: restricting untrusted userspace code to only be
    > > able to exec read/write/sigreturn.
    > >
    > > So this patch, unless i'm missing something, duplicates in essence what
    > > ptrace can do [...]
    >
    > there's one thing ptrace wont do: if the ptrace parent dies unexpectedly
    > and the child was 'running' (there is a small window where the child

    You got it, I couldn't use ptrace right now. Pavel already suggested it
    and I told him the problem with the parent being killed by oom.

    > might not be stopped and where this may happen) then the child can get
    > runaway. While i think this is theoretical (UML doesnt suffer from this
    > problem), it is simple to fix - find below a proof-of-concept patch that
    > introduces PTRACE_ATTACH_JAIL - ptraced children can never escape out of
    > such a jail. (barely tested - but you get the idea.)

    IMHO the complexity of ptrace makes it by definition less secure than
    seccomp. Seccomp is extremely simple and self contained. This is why I
    still prefer seccomp to fixing ptrace w.r.t. security.

    Fixing ptrace w.r.t. security-tracing it'd be still nice, but I'd prefer
    not to relay on ptrace when something as simple and robust as seccomp
    can be implemented instead.

    However if the kerneel folks wants me to use a "fixed version of
    ptrace", I could use it too (performance isn't the issue). In _theory_
    you're right it'd be completely equivalent after fixing the problem with
    the parent dying unexpectedly. But from my part in practice I prefer to
    relay _only_ on the much simpler seccomp patch (and on trusted computing
    as soon as the hardware is available).

    Even trusted computing will be less secure than seccomp from the point
    of view of the seller (because it's a lot more complicated than
    seccomp), but unlike with ptrace, the buyer will get both privacy
    guarantees and guarantees about reliably results too (only against
    software attacks). Having those two guarantees for the buyer will be
    fundamental, so it will worth to decrease the seller security a bit to
    give these guarantees to the buyer (I'll most certainly leave an
    exchange for seccomp at the same time I start the trusted computing
    exchange, so if some seller doesn't trust the trusted computing code,
    they can stick with the very secure seccomp approach), but right now,
    seccomp seems the most secure solution from the seller standpoint, and
    the buyer won't notice the difference between ptrace and seccomp.

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

    \
     
     \ /
      Last update: 2005-03-22 14:09    [W:4.287 / U:0.904 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site