[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <19490.1306434174@turing-police.cc.vt.edu>
Date: Thu, 26 May 2011 14:22:54 -0400
From: Valdis.Kletnieks@...edu
To: Will Drewry <wad@...omium.org>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
Colin Walters <walters@...bum.org>,
Kees Cook <kees.cook@...onical.com>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...e.hu>,
Peter Zijlstra <peterz@...radead.org>,
Steven Rostedt <rostedt@...dmis.org>,
linux-kernel@...r.kernel.org, James Morris <jmorris@...ei.org>
Subject: Re: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filtering
On Thu, 26 May 2011 13:08:10 CDT, Will Drewry said:
> Depending on the need, there is work involved, and there are many ways
> to determine your bounding box. It can be very tight -- where you
> analyze normal workloads (perf,strace,objdump) and accept the fact
> that pathological workloads may result in process death -- or it can
> be quite loose and enable most system calls, just not newer ones,
> let's say. In practice, you might get bit a few times if you're
> overly zealous (I know I have), but it's the difference between
> failing open and failing closed. There are some scenarios where you
> never, ever want to fail-open even at the cost of process death and
> lack of solid insight into a valid failure path.
> Hope that makes sense and isn't too general,
Oh, I already understood all that. :) I'd have to double-check the actual
patch, does it give a (hopefully rate-limited) printk or other hint which
syscall caused the issue, to help in making up the list of needed syscalls?
And we probably want a cleaned-up copy of the quoted paragraph in the
documentation for this feature when it hits the streets. People tuning in late
will need guidance on how to use this in their projects.
Content of type "application/pgp-signature" skipped
Powered by blists - more mailing lists