On Thu 2009-05-07 12:11:29, Ingo Molnar wrote:
* Nicholas Miell nmi...@comcast.net wrote:
On Wed, 2009-05-06 at 15:21 -0700, Markus Gutschke (?) wrote:
On Wed, May 6, 2009 at 15:13, Ingo Molnar mi...@elte.hu wrote:
doing a (per arch) bitmap of harmless syscalls and replacing
Markus Gutschke (ÜÒÐ) mar...@google.com writes:
There are a large number of system calls that normal C/C++ code uses
quite frequently, and that are not security sensitive. A typical
example would be gettimeofday().
At least on x86-64 gettimeofday() (and time(2)) work inside seccomp because
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
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
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
On Thu, May 7, 2009 at 00:03, Roland McGrath rol...@redhat.com wrote:
That is not a ptrace problem per se at all. It's an intrinsic problem
with any method based on generic syscall interception, if the filtering
and enforcement decisions depend on examining user memory.
Yes, this is indeed
* Markus Gutschke (顧孟勤) mar...@google.com wrote:
On Wed, May 6, 2009 at 14:29, Ingo Molnar mi...@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
On Sat, Feb 28, 2009 at 10:23, Linus Torvalds torva...@linux-foundation.org
wrote:
And I guess the seccomp interaction means that this is potentially a
2.6.29 thing. Not that I know whether anybody actually _uses_ seccomp. It
does seem to be enabled in at least Fedora kernels, but it might
On Sat, Feb 28, 2009 at 10:23, Linus Torvalds
torva...@linux-foundation.org wrote:
And I guess the seccomp interaction means that this is potentially a
2.6.29 thing. Not that I know whether anybody actually _uses_ seccomp. It
does seem to be enabled in at least Fedora kernels, but it might not
On Wed, May 6, 2009 at 14:29, Ingo Molnar mi...@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
On Wed, May 6, 2009 at 14:54, Ingo Molnar mi...@elte.hu wrote:
Which other system calls would you like to use? Futexes might be
one, for fast synchronization primitives?
There are a large number of system calls that normal C/C++ code uses
quite frequently, and that are not security sensitive. A
* Markus Gutschke (顧孟勤) mar...@google.com wrote:
On Wed, May 6, 2009 at 14:54, Ingo Molnar mi...@elte.hu wrote:
Which other system calls would you like to use? Futexes might be
one, for fast synchronization primitives?
There are a large number of system calls that normal C/C++ code
On Wed, May 6, 2009 at 15:13, Ingo Molnar mi...@elte.hu wrote:
doing a (per arch) bitmap of harmless syscalls and replacing the
mode1_syscalls[] check with that in kernel/seccomp.c would be a
pretty reasonable extension. (.config controllable perhaps, for
old-style-seccomp)
It would probably
* Markus Gutschke (顧孟勤) mar...@google.com wrote:
On Sat, Feb 28, 2009 at 10:23, Linus Torvalds
torva...@linux-foundation.org wrote:
And I guess the seccomp interaction means that this is
potentially a 2.6.29 thing. Not that I know whether anybody
actually _uses_ seccomp. It does seem
On Wed, 2009-05-06 at 15:21 -0700, Markus Gutschke (顧孟勤) wrote:
On Wed, May 6, 2009 at 15:13, Ingo Molnar mi...@elte.hu wrote:
doing a (per arch) bitmap of harmless syscalls and replacing the
mode1_syscalls[] check with that in kernel/seccomp.c would be a
pretty reasonable extension.
On Fri, 27 Feb 2009, Roland McGrath wrote:
I don't know any other arch well enough to be sure that TIF_32BIT isn't the
wrong test there too. I'd like to leave that worry to the arch maintainers.
Agreed - it may be that others will want to not use TIF_32BIT too. It
really does make much
On Sat, Feb 28, 2009 at 09:23:36AM -0800, Linus Torvalds wrote:
On Fri, 27 Feb 2009, Roland McGrath wrote:
But here is the patch you asked for.
Yes, this looks much more straightforward.
And I guess the seccomp interaction means that this is potentially a
2.6.29 thing. Not that I know
On Sat, 28 Feb 2009 09:46:01 -0800
Greg KH g...@kroah.com wrote:
On Sat, Feb 28, 2009 at 09:23:36AM -0800, Linus Torvalds wrote:
On Fri, 27 Feb 2009, Roland McGrath wrote:
But here is the patch you asked for.
Yes, this looks much more straightforward.
And I guess the seccomp
On Sat, Feb 28, 2009 at 09:54:33AM -0800, Arjan van de Ven wrote:
On Sat, 28 Feb 2009 09:46:01 -0800
Greg KH g...@kroah.com wrote:
On Sat, Feb 28, 2009 at 09:23:36AM -0800, Linus Torvalds wrote:
On Fri, 27 Feb 2009, Roland McGrath wrote:
But here is the patch you asked for.
On Sat, Feb 28, 2009 at 10:23:13AM -0800, Greg KH wrote:
On Sat, Feb 28, 2009 at 09:54:33AM -0800, Arjan van de Ven wrote:
On Sat, 28 Feb 2009 09:46:01 -0800
Greg KH g...@kroah.com wrote:
On Sat, Feb 28, 2009 at 09:23:36AM -0800, Linus Torvalds wrote:
On Fri, 27 Feb 2009, Roland
On Sat, 2009-02-28 at 09:23 -0800, Linus Torvalds wrote:
On Fri, 27 Feb 2009, Roland McGrath wrote:
I don't know any other arch well enough to be sure that TIF_32BIT isn't the
wrong test there too. I'd like to leave that worry to the arch maintainers.
Agreed - it may be that others
Ok, I can see what's going on. And it's disgusting.
That's what I thought when I saw TIF_32BIT in seccomp.
I did the simplest fix I could see touching only x86.
I don't know any other arch well enough to be sure that TIF_32BIT isn't the
wrong test there too. I'd like to leave that worry to
* Roland McGrath rol...@redhat.com wrote:
+#ifdef CONFIG_COMPAT
+ if (is_compat_task())
syscall = mode1_syscalls_32;
#endif
btw., shouldnt is_compat_task() expand to 0 in the
!CONFIG_COMPAT case? That way we could remove this #ifdef too.
(and move the
btw., shouldnt is_compat_task() expand to 0 in the
!CONFIG_COMPAT case? That way we could remove this #ifdef too.
(and move the first #ifdef inside the array initialization so
that we always have a mode1_syscalls_32[] array.)
I guess you mean define it in linux/compat.h then?
Go right
24 matches
Mail list logo
