Andrea Arcangeli wrote:
>On Sun, Jan 23, 2005 at 07:34:24AM +, David Wagner wrote:
>> [...Ostia...] The jailed process inherit an open file
>> descriptor to its jailor, and is only allowed to call read(), write(),
>> sendmsg(), and recvmsg(). [...]
>
>Why to call sendmsg/recvmsg when you can
On Sun, Jan 23, 2005 at 07:34:24AM +, David Wagner wrote:
> What if 6 months from now we discover that we really should have enabled
> one more syscall in seccomp to accomodate other applications?
This is why there's a seccomp mode number, and you've to choose it, I
only implemented mode 0 so
On Sun, Jan 23, 2005 at 07:34:24AM +, David Wagner wrote:
> Chris Wright wrote:
> >* David Wagner ([EMAIL PROTECTED]) wrote:
> >> There is a simple tweak to ptrace which fixes that: one could add an
> >> API to specify a set of syscalls that ptrace should not trap on. To get
> >> seccomp-like
Chris Wright wrote:
>* David Wagner ([EMAIL PROTECTED]) wrote:
>> There is a simple tweak to ptrace which fixes that: one could add an
>> API to specify a set of syscalls that ptrace should not trap on. To get
>> seccomp-like semantics, the user program could specify {read,write}, but
>> if the u
On Sat, Jan 22, 2005 at 11:43:06PM -0500, [EMAIL PROTECTED] wrote:
> It's a poor idea to confuse "secure" with "can't break out of the sandbox".
The only point I'm making with seccomp, is that if it can't break out of
the sandbox it's secure. I didn't mean that the only way to make it
secure is to
On Sun, 23 Jan 2005 01:52:13 +0100, Andrea Arcangeli said:
> Why should I be kidding? The client code I'm doing, has to be at least as
> secure
Maybe in your estimation it *has* to be that secure. However, actual experience
with other operating systems indicate that the mail programs and web br
On Sat, Jan 22, 2005 at 07:43:26PM -0500, Rik van Riel wrote:
> On Sun, 23 Jan 2005, Andrea Arcangeli wrote:
>
> >I'm doing something that requires the maximum level of
> >security ever,
>
> You're kidding, right ?
Why should I be kidding? The client code I'm doing, has to be at least as secure
On Sun, Jan 23, 2005 at 01:07:04AM +0100, Pavel Machek wrote:
> Adding code is easy, but in the long term would lead to maintainance
> nightmare. Adding seccomp code that does subset of ptrace, just
> because ptrace audit is lot of work, seems like a wrong thing to
> do. Sorry.
Even if I do the pt
On Sun, 23 Jan 2005, Andrea Arcangeli wrote:
I'm doing something that requires the maximum level of
security ever,
You're kidding, right ?
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not sma
Hi!
> > Well, then you can help auditing ptrace()... It is probably also true
> > that more people audited ptrace() than seccomp :-).
>
> Why should I spend time auditing ptrace when I have a superior solution
> that doesn't require me any auditing at all? I've an huge pile of
> work,
Adding cod
On Sat, Jan 22, 2005 at 08:42:42PM +0100, Pavel Machek wrote:
> Well, then you can help auditing ptrace()... It is probably also true
> that more people audited ptrace() than seccomp :-).
Why should I spend time auditing ptrace when I have a superior solution
that doesn't require me any auditing a
Hi!
> > Well, seccomp is also getting very little testing, when ptrace gets a
> > lot of testing; I know that seccomp is simple, but I believe testing
> > coverage still make ptrace better choice.
>
> It's not testing that makes code more secure. Testing verifys the code
> works in production, bu
On Sat, Jan 22, 2005 at 11:32:42AM +0100, Pavel Machek wrote:
> Well, seccomp is also getting very little testing, when ptrace gets a
> lot of testing; I know that seccomp is simple, but I believe testing
> coverage still make ptrace better choice.
It's not testing that makes code more secure. Tes
Hi!
> > > > Yes, but do you care about the performance of syscalls
> > > > which the program isn't allowed to call at all ? ;)
> > >
> > > Heh, no, but it's for every syscall not just denied ones. Point is
> > > simply that ptrace (complexity aside) doesn't scale the same.
> >
> > seccomp is ab
On Fri, Jan 21, 2005 at 01:31:46PM -0800, Roland McGrath wrote:
> When gdb has a bug, people want to be able to kill it and get on with using
> their program, not have their program always be killed too.
What I need is that the program is killed right away synchronously as
soon as the "debugger" d
On Fri, Jan 21, 2005 at 09:54:16PM +0100, Ingo Molnar wrote:
> - the second barrier is the 'jail' of the ptraced task. Especially with
> PTRACE_SYSCALL, the things a child ptraced process can do are
> extremely limited, everything it tries to do will trap, the task will
> suspend and the pare
> maybe this could even be fit into existing ptrace semantics, without any
> need for PTRACE_ATTACH_JAIL. What we need is to catch the case where a
> ptraced child is running (i.e. the signal_wake_up() has already been
> done, and the parent is waiting for the child to stop again), and the
> ptrace
* Andrea Arcangeli <[EMAIL PROTECTED]> wrote:
> Indeed. Performance is not an issue (in the short term at least, since
> those syscalls will be probably network bound).
>
> The only reason I couldn't use ptrace is what you found, that is the
> oom killing of the parent (or a mistake of the CPU s
On Fri, Jan 21, 2005 at 08:55:22PM +0100, Ingo Molnar wrote:
>
> * Chris Wright <[EMAIL PROTECTED]> wrote:
>
> > * Rik van Riel ([EMAIL PROTECTED]) wrote:
> > > Yes, but do you care about the performance of syscalls
> > > which the program isn't allowed to call at all ? ;)
> >
> > Heh, no, but i
On Fri, Jan 21, 2005 at 01:47:01PM +0100, Ingo Molnar wrote:
>
> * Ingo Molnar <[EMAIL PROTECTED]> 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 ke
* Chris Wright <[EMAIL PROTECTED]> wrote:
> * Rik van Riel ([EMAIL PROTECTED]) wrote:
> > Yes, but do you care about the performance of syscalls
> > which the program isn't allowed to call at all ? ;)
>
> Heh, no, but it's for every syscall not just denied ones. Point is
> simply that ptrace (c
* David Wagner ([EMAIL PROTECTED]) wrote:
> There is a simple tweak to ptrace which fixes that: one could add an
> API to specify a set of syscalls that ptrace should not trap on. To get
> seccomp-like semantics, the user program could specify {read,write}, but
> if the user program ever wants to
Chris Wright wrote:
>Only difference is in number of context switches, and number of running
>processes (and perhaps ease of determining policy for which syscalls
>are allowed). Although it's not really seccomp, it's just restricted
>syscalls...
There is a simple tweak to ptrace which fixes that
* Rik van Riel ([EMAIL PROTECTED]) wrote:
> Yes, but do you care about the performance of syscalls
> which the program isn't allowed to call at all ? ;)
Heh, no, but it's for every syscall not just denied ones. Point is
simply that ptrace (complexity aside) doesn't scale the same.
thanks,
-chris
On Fri, 21 Jan 2005, Chris Wright wrote:
* Ingo Molnar ([EMAIL PROTECTED]) wrote:
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.
Only difference is in number of context s
* Ingo Molnar ([EMAIL PROTECTED]) wrote:
>
> * Andrea Arcangeli <[EMAIL PROTECTED]> 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
* Ingo Molnar <[EMAIL PROTECTED]> 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 implement
* Ingo Molnar <[EMAIL PROTECTED]> 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: restr
Hi!
> 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). This is
> against 2.6.11-rc1-bk8. The progress is on schedule so far, so it
> might
It needs entry in Documentation/ at least.
* Andrea Arcangeli <[EMAIL PROTECTED]> 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
Hello,
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). This is
against 2.6.11-rc1-bk8. The progress is on schedule so far, so it might
not be a bad idea to merge this into the kernel sooner than later, so that
the
31 matches
Mail list logo
