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
| ||
|
Date: Sat, 23 Jan 2010 07:03:01 -0500 From: "Frank Ch. Eigler" <fche@...hat.com> To: Ingo Molnar <mingo@...e.hu> Cc: Linus Torvalds <torvalds@...ux-foundation.org>, Steven Rostedt <rostedt@...dmis.org>, Fr??d??ric Weisbecker <fweisbec@...il.com>, Arnaldo Carvalho de Melo <acme@...hat.com>, Li Zefan <lizf@...fujitsu.com>, Tom Zanussi <tzanussi@...il.com>, systemtap@...rces.redhat.com, dle-develop@...ts.sourceforge.net, Andrew Morton <akpm@...ux-foundation.org>, Stephen Rothwell <sfr@...b.auug.org.au>, Ananth N Mavinakayanahalli <ananth@...ibm.com>, Peter Zijlstra <a.p.zijlstra@...llo.nl>, Peter Zijlstra <peterz@...radead.org>, LKML <linux-kernel@...r.kernel.org>, linux-next@...r.kernel.org, "H. Peter Anvin" <hpa@...or.com>, utrace-devel@...hat.com, Thomas Gleixner <tglx@...utronix.de> Subject: Re: linux-next: add utrace tree Hi - On Sat, Jan 23, 2010 at 07:04:01AM +0100, Ingo Molnar wrote: > [...] Also, if any systemtap person is interested in helping us > create a more generic filter engine out of the current ftrace filter > engine (which is really a precursor of a safe, sandboxed in-kernel > script engine), that would be excellent as well. [...] Thank you for the invitation. > More could be done - a simple C-like set of function perhaps - some minimal > per probe local variable state, etc. (perhaps even looping as well, with a > limit on number of predicament executions per filter invocation.) Yes, at some point when such bytecode intepreter gets rich enough, one may not need the translated-to-C means of running scripts. > ( _Such_ a facility, could then perhaps be used to allow applications access > to safe syscall sandboxing techniques: i.e. a programmable seccomp concept > in essence, controlled via ASCII space filter expressions [...] > IMHO that would be a superior concept for security modules too [...] > > [...] specific functionality with an immediately visible upside, > with no need for opaque hooks. This OTOH seem like rather a stretch. If one claims that "opaque hooks" are bad, so instead have hooks that jump not to auditable C code but an bytecode interpreter? And have the bytecodes be uploaded from userspace? How is this supposed to produce "transparency" from the kernel/hook point of view? - FChE -- 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/
Powered by blists - more mailing lists