* Peter Zijlstra pet...@infradead.org wrote:
But face it, you can argue until you're blue in the face,
That is not a technical argument though - and i considered and
answered every valid technical argument made by you and Thomas.
You were either not able to or not willing to counter them.
On Mon 2011-05-16 10:36:05, James Morris wrote:
On Fri, 13 May 2011, Ingo Molnar wrote:
How do you reason about the behavior of the system as a whole?
I argue that this is the LSM and audit subsystems designed right: in the
long
run it could allow everything that LSM does at the
* Pavel Machek pa...@ucw.cz wrote:
On Mon 2011-05-16 10:36:05, James Morris wrote:
On Fri, 13 May 2011, Ingo Molnar wrote:
How do you reason about the behavior of the system as a whole?
I argue that this is the LSM and audit subsystems designed right: in the
long
run it
* Thomas Gleixner t...@linutronix.de wrote:
We do _NOT_ make any decision based on the trace point so
what's the pre-existing active role in the syscall entry
code?
The seccomp code we are discussing in this thread.
That's proposed code and has absolutely nothing to do with
On Tue, 24 May 2011, Ingo Molnar wrote:
* Peter Zijlstra pet...@infradead.org wrote:
On Tue, 2011-05-24 at 10:59 -0500, Will Drewry wrote:
include/linux/ftrace_event.h |4 +-
include/linux/perf_event.h| 10 +---
kernel/perf_event.c | 49
* Thomas Gleixner t...@linutronix.de wrote:
On Tue, 24 May 2011, Ingo Molnar wrote:
* Peter Zijlstra pet...@infradead.org wrote:
On Tue, 2011-05-24 at 10:59 -0500, Will Drewry wrote:
include/linux/ftrace_event.h |4 +-
include/linux/perf_event.h| 10 +---
On Wed, 2011-05-25 at 17:01 +0200, Ingo Molnar wrote:
We do _NOT_ make any decision based on the trace point so what's the
pre-existing active role in the syscall entry code?
The seccomp code we are discussing in this thread.
That isn't pre-existing, that's proposed.
But face it, you can
On Wed, 25 May 2011, Ingo Molnar wrote:
* Thomas Gleixner t...@linutronix.de wrote:
On Tue, 24 May 2011, Ingo Molnar wrote:
* Peter Zijlstra pet...@infradead.org wrote:
On Tue, 2011-05-24 at 10:59 -0500, Will Drewry wrote:
include/linux/ftrace_event.h |4 +-
On Thu, May 19, 2011 at 4:05 PM, Will Drewry w...@chromium.org wrote:
On Thu, May 19, 2011 at 7:22 AM, Steven Rostedt rost...@goodmis.org wrote:
On Wed, 2011-05-18 at 21:07 -0700, Will Drewry wrote:
Do event_* that return non-void exist in the tree at all now? I've
looked at the various
On Tue, 2011-05-24 at 10:59 -0500, Will Drewry wrote:
include/linux/ftrace_event.h |4 +-
include/linux/perf_event.h| 10 +---
kernel/perf_event.c | 49 +---
kernel/seccomp.c |8 ++
On Tue, 24 May 2011, Peter Zijlstra wrote:
On Tue, 2011-05-24 at 10:59 -0500, Will Drewry wrote:
include/linux/ftrace_event.h |4 +-
include/linux/perf_event.h| 10 +---
kernel/perf_event.c | 49
+---
kernel/seccomp.c
On Tue, May 24, 2011 at 11:25 AM, Thomas Gleixner t...@linutronix.de wrote:
On Tue, 24 May 2011, Peter Zijlstra wrote:
On Tue, 2011-05-24 at 10:59 -0500, Will Drewry wrote:
include/linux/ftrace_event.h | 4 +-
include/linux/perf_event.h | 10 +---
kernel/perf_event.c
* Peter Zijlstra pet...@infradead.org wrote:
On Tue, 2011-05-24 at 10:59 -0500, Will Drewry wrote:
include/linux/ftrace_event.h |4 +-
include/linux/perf_event.h| 10 +---
kernel/perf_event.c | 49
+---
kernel/seccomp.c
* Will Drewry w...@chromium.org wrote:
The change avoids defining a new trace call type or a huge number of internal
changes and hides seccomp.mode=2 from ABI-exposure in prctl, but the attack
surface is non-trivial to verify, and I'm not sure if this ABI change makes
sense. It amounts
* Ingo Molnar mi...@elte.hu wrote:
* Peter Zijlstra pet...@infradead.org wrote:
On Tue, 2011-05-24 at 10:59 -0500, Will Drewry wrote:
include/linux/ftrace_event.h |4 +-
include/linux/perf_event.h| 10 +---
kernel/perf_event.c | 49
On Tue, 2011-05-24 at 22:08 +0200, Ingo Molnar wrote:
* Will Drewry w...@chromium.org wrote:
But there could be a perf_tp_event_ret() or perf_tp_event_check() entry that
code like seccomp which wants to use event results can use.
We should name it something else. The perf_tp.. is a misnomer
On Wed, 2011-05-18 at 21:07 -0700, Will Drewry wrote:
Do event_* that return non-void exist in the tree at all now? I've
looked at the various tracepoint macros as well as some of the other
handlers (trace_function, perf_tp_event, etc) and I'm not seeing any
places where a return value is
On Thu, May 19, 2011 at 7:22 AM, Steven Rostedt rost...@goodmis.org wrote:
On Wed, 2011-05-18 at 21:07 -0700, Will Drewry wrote:
Do event_* that return non-void exist in the tree at all now? I've
looked at the various tracepoint macros as well as some of the other
handlers (trace_function,
On Tue, May 17, 2011 at 6:19 AM, Ingo Molnar mi...@elte.hu wrote:
* Steven Rostedt rost...@goodmis.org wrote:
On Tue, 2011-05-17 at 14:42 +0200, Ingo Molnar wrote:
* Steven Rostedt rost...@goodmis.org wrote:
On Mon, 2011-05-16 at 18:52 +0200, Ingo Molnar wrote:
* Steven Rostedt
* Steven Rostedt rost...@goodmis.org wrote:
On Mon, 2011-05-16 at 18:52 +0200, Ingo Molnar wrote:
* Steven Rostedt rost...@goodmis.org wrote:
I'm a bit nervous about the 'active' role of (trace_)events, because of
the
way multiple callbacks can be registered. How would:
* Will Drewry w...@chromium.org wrote:
This is *far* more generic still yields the same short-term end result as
far as your sandboxing is concerned.
Almost :/ [...]
Hey that's a pretty good result from a subsystem that was not written with your
usecase in mind *at all* ;-)
[...] I
On Tue, 2011-05-17 at 14:42 +0200, Ingo Molnar wrote:
* Steven Rostedt rost...@goodmis.org wrote:
On Mon, 2011-05-16 at 18:52 +0200, Ingo Molnar wrote:
* Steven Rostedt rost...@goodmis.org wrote:
I'm a bit nervous about the 'active' role of (trace_)events, because of
the
* James Morris jmor...@namei.org wrote:
On Tue, 17 May 2011, Ingo Molnar wrote:
I'm not sure i get your point.
Your example was not complete as described. After an apparently simple
specification, you've since added several qualifiers and assumptions, [...]
I havent added any
* Arnd Bergmann a...@arndb.de wrote:
On Saturday 14 May 2011, Will Drewry wrote:
Depending on integration, it could even be limited to ioctl commands
that are appropriate to a known fd if the fd is opened prior to
entering seccomp mode 2. Alternatively, __NR__ioctl could be allowed
with
* Will Drewry w...@chromium.org wrote:
Note, i'm not actually asking for the moon, a pony and more.
I fully submit that we are yet far away from being able to do a full LSM
via this mechanism.
What i'm asking for is that because the syscall point steps taken by Will
look very
* Will Drewry w...@chromium.org wrote:
I agree with you on many of these points! However, I don't think that the
views around LSMs, perf/ftrace infrastructure, or the current seccomp
filtering implementation are necessarily in conflict. Here is my
understanding of how the different
On Mon, May 16, 2011 at 7:55 AM, Ingo Molnar mi...@elte.hu wrote:
* Will Drewry w...@chromium.org wrote:
I agree with you on many of these points! However, I don't think that the
views around LSMs, perf/ftrace infrastructure, or the current seccomp
filtering implementation are necessarily
* James Morris jmor...@namei.org wrote:
On Fri, 13 May 2011, Ingo Molnar wrote:
Say i'm a user-space sandbox developer who wants to enforce that sandboxed
code should only be allowed to open files in /home/sandbox/, /lib/ and
/usr/lib/.
It is a simple and sensible security
On Mon, May 16, 2011 at 10:26 AM, Steven Rostedt rost...@goodmis.org wrote:
Sorry to be absent from this thread so far, I just got back from my
travels and I'm now catching up on email.
On Wed, 2011-05-11 at 22:02 -0500, Will Drewry wrote:
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
On Mon, May 16, 2011 at 7:43 AM, Ingo Molnar mi...@elte.hu wrote:
* Will Drewry w...@chromium.org wrote:
Note, i'm not actually asking for the moon, a pony and more.
I fully submit that we are yet far away from being able to do a full LSM
via this mechanism.
What i'm asking for is
Sorry to be absent from this thread so far, I just got back from my
travels and I'm now catching up on email.
On Wed, 2011-05-11 at 22:02 -0500, Will Drewry wrote:
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 377a7a5..22e1668 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
* Steven Rostedt rost...@goodmis.org wrote:
I'm a bit nervous about the 'active' role of (trace_)events, because of the
way multiple callbacks can be registered. How would:
err = event_x();
if (err == -EACCESS) {
be handled? [...]
The default behavior would be something
On Mon, 2011-05-16 at 18:52 +0200, Ingo Molnar wrote:
* Steven Rostedt rost...@goodmis.org wrote:
I'm a bit nervous about the 'active' role of (trace_)events, because of the
way multiple callbacks can be registered. How would:
err = event_x();
if (err == -EACCESS) {
be
On Mon, 16 May 2011, Ingo Molnar wrote:
Not really.
Firstly, what is the security goal of these restrictions? [...]
To do what i described above? Namely:
Sandboxed code should only be allowed to open files in /home/sandbox/,
/lib/
and /usr/lib/
These are access rules, they
On Saturday 14 May 2011, Will Drewry wrote:
Depending on integration, it could even be limited to ioctl commands
that are appropriate to a known fd if the fd is opened prior to
entering seccomp mode 2. Alternatively, __NR__ioctl could be allowed
with a filter of 1 then narrowed through a later
On Fri, 13 May 2011, Ingo Molnar wrote:
Say i'm a user-space sandbox developer who wants to enforce that sandboxed
code
should only be allowed to open files in /home/sandbox/, /lib/ and /usr/lib/.
It is a simple and sensible security feature, agreed? It allows most code to
run well and
* Peter Zijlstra pet...@infradead.org wrote:
On Fri, 2011-05-13 at 16:57 +0200, Ingo Molnar wrote:
this is a security mechanism
Who says? [...]
Kernel developers/maintainers of the affected code.
We have security hooks all around the kernel, which can deny/accept execution
at various
On Sat, May 14, 2011 at 2:30 AM, Ingo Molnar mi...@elte.hu wrote:
* Eric Paris epa...@redhat.com wrote:
[dropping microblaze and roland]
lOn Fri, 2011-05-13 at 14:10 +0200, Ingo Molnar wrote:
* James Morris jmor...@namei.org wrote:
It is a simple and sensible security feature, agreed?
On Thursday 12 May 2011, Will Drewry wrote:
This change adds a new seccomp mode based on the work by
a...@chromium.org in [1]. This new mode, filter mode, provides a hash
table of seccomp_filter objects. When in the new mode (2), all system
calls are checked against the filters - first by
On Fri, May 13, 2011 at 2:35 PM, Arnd Bergmann a...@arndb.de wrote:
On Thursday 12 May 2011, Will Drewry wrote:
This change adds a new seccomp mode based on the work by
a...@chromium.org in [1]. This new mode, filter mode, provides a hash
table of seccomp_filter objects. When in the new mode
* Peter Zijlstra pet...@infradead.org wrote:
On Fri, 2011-05-13 at 14:10 +0200, Ingo Molnar wrote:
err = event_vfs_getname(result);
I really think we should not do this. Events like we have them should be
inactive, totally passive entities, only observe but not affect execution
On Fri, 2011-05-13 at 14:26 +0200, Ingo Molnar wrote:
* Peter Zijlstra pet...@infradead.org wrote:
On Fri, 2011-05-13 at 14:10 +0200, Ingo Molnar wrote:
err = event_vfs_getname(result);
I really think we should not do this. Events like we have them should be
inactive,
On Fri, 2011-05-13 at 14:39 +0200, Peter Zijlstra wrote:
event_vfs_getname(result);
result = check_event_vfs_getname(result);
Another fundamental difference is how to treat the callback chains for
these two.
Observers won't have a return value and are assumed to never fail,
* Peter Zijlstra pet...@infradead.org wrote:
Why should we have two callbacks next to each other:
event_vfs_getname(result);
result = check_event_vfs_getname(result);
if one could do it all?
Did you actually read the bit where I said that check_event_* (although
I still
* Peter Zijlstra pet...@infradead.org wrote:
On Fri, 2011-05-13 at 14:39 +0200, Peter Zijlstra wrote:
event_vfs_getname(result);
result = check_event_vfs_getname(result);
Another fundamental difference is how to treat the callback chains for
these two.
Observers
On Fri, 2011-05-13 at 14:54 +0200, Ingo Molnar wrote:
I think the sanest semantics is to run all active callbacks as well.
For example if this is used for three stacked security policies - as if 3 LSM
modules were stacked at once. We'd call all three, and we'd determine that at
least one
* Peter Zijlstra pet...@infradead.org wrote:
On Fri, 2011-05-13 at 14:54 +0200, Ingo Molnar wrote:
I think the sanest semantics is to run all active callbacks as well.
For example if this is used for three stacked security policies - as if 3
LSM
modules were stacked at once. We'd
On Fri, 2011-05-13 at 14:49 +0200, Ingo Molnar wrote:
So given that by your own admission it makes sense to share the facilities at
the low level, i also argue that it makes sense to share as high up as
possible.
I'm not saying any such thing, I'm saying that it might make sense to
Cut the microblaze list since its bouncy.
On Fri, 2011-05-13 at 15:18 +0200, Ingo Molnar wrote:
* Peter Zijlstra pet...@infradead.org wrote:
On Fri, 2011-05-13 at 14:54 +0200, Ingo Molnar wrote:
I think the sanest semantics is to run all active callbacks as well.
For example if
* Peter Zijlstra pet...@infradead.org wrote:
Cut the microblaze list since its bouncy.
On Fri, 2011-05-13 at 15:18 +0200, Ingo Molnar wrote:
* Peter Zijlstra pet...@infradead.org wrote:
On Fri, 2011-05-13 at 14:54 +0200, Ingo Molnar wrote:
I think the sanest semantics is to run
* Peter Zijlstra pet...@infradead.org wrote:
On Fri, 2011-05-13 at 14:49 +0200, Ingo Molnar wrote:
So given that by your own admission it makes sense to share the facilities
at
the low level, i also argue that it makes sense to share as high up as
possible.
I'm not saying any
[dropping microblaze and roland]
lOn Fri, 2011-05-13 at 14:10 +0200, Ingo Molnar wrote:
* James Morris jmor...@namei.org wrote:
It is a simple and sensible security feature, agreed? It allows most code to
run well and link to countless libraries - but no access to other files is
allowed.
[dropping microblaze and roland]
On Fri, 2011-05-13 at 15:18 +0200, Ingo Molnar wrote:
* Peter Zijlstra pet...@infradead.org wrote:
On Fri, 2011-05-13 at 14:54 +0200, Ingo Molnar wrote:
I think the sanest semantics is to run all active callbacks as well.
For example if this is used
On Fri, 2011-05-13 at 11:10 -0400, Eric Paris wrote:
Then again, I certainly don't see a
reason that this syscall hardening patch should be held up while a whole
new concept in computer security is contemplated...
Which makes me wonder why this syscall hardening stuff is done outside
of LSM?
On Fri, 2011-05-13 at 16:57 +0200, Ingo Molnar wrote:
this is a security mechanism
Who says? and why would you want to unify two separate concepts only to
them limit it to security that just doesn't make sense.
Either you provide a full on replacement for notifier chain like things
or you
* James Morris jmor...@namei.org wrote:
On Thu, 12 May 2011, Ingo Molnar wrote:
Funnily enough, back then you wrote this:
I'm concerned that we're seeing yet another security scheme being
designed on
the fly, without a well-formed threat model, and without taking into
On Fri, 2011-05-13 at 17:23 +0200, Peter Zijlstra wrote:
On Fri, 2011-05-13 at 11:10 -0400, Eric Paris wrote:
Then again, I certainly don't see a
reason that this syscall hardening patch should be held up while a whole
new concept in computer security is contemplated...
Which makes me
On Fri, May 13, 2011 at 10:55 AM, Eric Paris epa...@redhat.com wrote:
On Fri, 2011-05-13 at 17:23 +0200, Peter Zijlstra wrote:
On Fri, 2011-05-13 at 11:10 -0400, Eric Paris wrote:
Then again, I certainly don't see a
reason that this syscall hardening patch should be held up while a whole
Ok, i like the direction here, but i think the ABI should be done differently.
In this patch the ftrace event filter mechanism is used:
* Will Drewry w...@chromium.org wrote:
+static struct seccomp_filter *alloc_seccomp_filter(int syscall_nr,
+
Hi,
On Thu, May 12, 2011 at 09:48:50AM +0200, Ingo Molnar wrote:
1) We already have a specific ABI for this: you can set filters for events
via
an event fd.
Why not extend that mechanism instead and improve *both* your sandboxing
bits and the events code? This new seccomp code
* Kees Cook kees.c...@canonical.com wrote:
Hi,
On Thu, May 12, 2011 at 09:48:50AM +0200, Ingo Molnar wrote:
1) We already have a specific ABI for this: you can set filters for events
via
an event fd.
Why not extend that mechanism instead and improve *both* your sandboxing
On Wed, 11 May 2011, Will Drewry wrote:
+void seccomp_filter_log_failure(int syscall)
+{
+ printk(KERN_INFO
+ %s[%d]: system call %d (%s) blocked at ip:%lx\n,
+ current-comm, task_pid_nr(current), syscall,
+ syscall_nr_to_name(syscall),
On Thu, 12 May 2011, Ingo Molnar wrote:
2) Why should this concept not be made available wider, to allow the
restriction of not just system calls but other security relevant
components
of the kernel as well?
Because the aim of this is to reduce the attack surface of the syscall
On Thu, May 12, 2011 at 09:48:50AM +0200, Ingo Molnar wrote:
To restrict execution to system calls.
Two observations:
1) We already have a specific ABI for this: you can set filters for events
via
an event fd.
Why not extend that mechanism instead and improve *both* your
* James Morris jmor...@namei.org wrote:
On Thu, 12 May 2011, Ingo Molnar wrote:
2) Why should this concept not be made available wider, to allow the
restriction of not just system calls but other security relevant
components
of the kernel as well?
Because the aim of this
[Thanks to everyone for the continued feedback and insights - I appreciate it!]
On Thu, May 12, 2011 at 8:01 AM, Ingo Molnar mi...@elte.hu wrote:
* James Morris jmor...@namei.org wrote:
On Thu, 12 May 2011, Ingo Molnar wrote:
2) Why should this concept not be made available wider, to allow
On Thu, 12 May 2011, Ingo Molnar wrote:
Funnily enough, back then you wrote this:
I'm concerned that we're seeing yet another security scheme being
designed on
the fly, without a well-formed threat model, and without taking into
account
lessons learned from the seemingly
67 matches
Mail list logo
