linux-kernel - Re: [PATCH v9 05/13] seccomp_filter: Document what seccomp

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20110701161027.GA29035@elte.hu>
Date:	Fri, 1 Jul 2011 18:10:27 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Will Drewry <wad@...omium.org>
Cc:	James Morris <jmorris@...ei.org>,
	Chris Evans <scarybeasts@...il.com>,
	linux-kernel@...r.kernel.org,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	djm@...drot.org, segoon@...nwall.com, kees.cook@...onical.com,
	rostedt@...dmis.org, fweisbec@...il.com, tglx@...utronix.de,
	Randy Dunlap <rdunlap@...otime.net>, linux-doc@...r.kernel.org,
	Eric Paris <eparis@...hat.com>,
	linux-security-module@...r.kernel.org
Subject: Re: [PATCH v9 05/13] seccomp_filter: Document what seccomp_filter is
 and how it works.


* Will Drewry <wad@...omium.org> 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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/