* Will Drewry <wad@xxxxxxxxxxxx> wrote:
> From my view, ftrace events are not ready for the job yet - and
> relying purely on available wrapped events may make it unsuitable
> for attack surface reduction forever. As is, there is no compat
> syscall support. Many syscalls are not wrapped at present and no
> one ack'd my earlier patches around wrapping more. All of perf
> needs to be overhauled to share per-task infrastructure. A new ABI
> needs to be proposed if my prctl() changes are not acceptable to
> handle some of the security-focused behavioral requirements.
> Performance characteristics need to be better analyzed as the
> current perf list_head approach may not scale as desired. The list
> goes on. My proof of concept patch for "event filters" was just
> that - a proof of concept. To truly share the filter events is a
> large amount of work that may not be viable, and I believe you know
> that as well as I do.
But that's exactly my point: i consider it the right way forward
because it maximizes kernel utility in the long run.
Note that *all* the specific technical items you mention:
- wrapping more syscalls (i.e. making syscall tracing
feature-complete)
- a clean filtering ABI
- performance improvements. (Note that this one is already
in progress, Thomas has written an IDR implementation that
eliminates the list iteration entirely. You could help him
finish it.)
are not some bad side effect or quirk, they are all generic
improvements we want in any case and not just for sandboxing.
You might not be interested in all of those items, you are only
interested in getting the narrow feature-set you are interested in,
but you sure are interested in getting sandboxing versus not getting
anything at all, right?
Not doing it right because "it's too much work", especially as the
trivial 'proof of concept' prototype already gave us something very
promising that worked to a fair degree:
bitmask (2009): 6 files changed, 194 insertions(+), 22 deletions(-)
filter engine (2010): 18 files changed, 1100 insertions(+), 21 deletions(-)
event filters (2011): 5 files changed, 82 insertions(+), 16 deletions(-)
are pretty hollow arguments to me. That diffstat sums up my argument
of proper structure pretty well.
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
