linux-mips
[Top] [All Lists]

Re: [PATCH 2/2] x86-64: seccomp: fix 32/64 syscall hole

To: Ingo Molnar <mingo@elte.hu>
Subject: Re: [PATCH 2/2] x86-64: seccomp: fix 32/64 syscall hole
From: Markus Gutschke (顧孟勤) <markus@google.com>
Date: Wed, 6 May 2009 14:46:02 -0700
Cc: Linus Torvalds <torvalds@linux-foundation.org>, Roland McGrath <roland@redhat.com>, Andrew Morton <akpm@linux-foundation.org>, x86@kernel.org, linux-kernel@vger.kernel.org, stable@kernel.org, linux-mips@linux-mips.org, sparclinux@vger.kernel.org, linuxppc-dev@ozlabs.org
Dkim-signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1241646367; bh=B+n8K5SJbr7nW83ggAm+OtcVhXs=; h=DomainKey-Signature:MIME-Version:In-Reply-To:References:Date: Message-ID:Subject:From:To:Cc:Content-Type: Content-Transfer-Encoding:X-System-Of-Record; b=sgcHevYxaaH0Wx896A KAh3FS34pC7UNGkMgfQe8vEW4y5iuQfWGOd5RNA0P3Zqc953XSeJ3VDvbBncBtnWYHW g==
Domainkey-signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=Ar2KMOx4aReyeTxrq5BCWRCD7yovLpJwS9mhTxXqY182VRvuyHOwIeC97BzhcJDUL AfSvtZxR6MA1taTttiB4g==
In-reply-to: <20090506212913.GC4861@elte.hu>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <20090228030226.C0D34FC3DA@magilla.sf.frob.com> <20090228030413.5B915FC3DA@magilla.sf.frob.com> <alpine.LFD.2.00.0902271932520.3111@localhost.localdomain> <alpine.LFD.2.00.0902271948570.3111@localhost.localdomain> <20090228072554.CFEA6FC3DA@magilla.sf.frob.com> <alpine.LFD.2.00.0902280916470.3111@localhost.localdomain> <904b25810905061146ged374f2se0afd24e9e3c1f06@mail.gmail.com> <20090506212913.GC4861@elte.hu>
Sender: linux-mips-bounce@linux-mips.org
On Wed, May 6, 2009 at 14:29, Ingo Molnar <mingo@elte.hu> wrote:
> That's a pretty interesting usage. What would be fallback mode you
> are using if the kernel doesnt have seccomp built in? Completely
> non-sandboxed? Or a ptrace/PTRACE_SYSCALL based sandbox?

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. It is very attractive that kernel automatically
terminates any application that violates the very well-defined
constraints of the sandbox.

In general, we are currently exploring different options based on
general availability, functionality, and complexity of implementation.
Seccomp is a good middle ground that we expect to be able to use in
the medium term to provide an acceptable solution for a large segment
of Linux users. Although the restriction to just four unfiltered
system calls is painful.

We are still discussing what fallback options we have, and they are
likely on different schedules.

For instance, on platforms that have AppArmor or SELinux, we might be
able to use them as part of our sandboxing solution. Although we are
still investigating whether they meet all of our needs.


Markus

<Prev in Thread] Current Thread [Next in Thread>