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
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 call
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:
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
> >>
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 semantics,
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
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
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
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
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
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
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
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,
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.
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
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 about CPU-intense
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.
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, but
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 at
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 code is
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
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
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
as ssh
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
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 put
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 user
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"
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
> 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
>
* 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
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
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
* 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
* 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
* 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,
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
* 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
* 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:
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
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
* 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
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.
* 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: restricting
* 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:
* 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 seems to be
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
* 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
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:
* 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
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 kernel code for
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 it's for every
* 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 seller
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
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 parent
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
61 matches
Mail list logo
