Date:	Fri, 08 May 2009 00:32:25 -0500
From:	Tom Zanussi <tzanussi@...il.com>
To:	Frederic Weisbecker <fweisbec@...il.com>
Cc:	Adam Langley <agl@...gle.com>, Ingo Molnar <mingo@...e.hu>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Li Zefan <lizf@...fujitsu.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	linux-kernel@...r.kernel.org, markus@...gle.com
Subject: Re: [RFC 1/1] seccomp: Add bitmask of allowed system calls.

On Fri, 2009-05-08 at 01:00 +0200, Frederic Weisbecker wrote:
> On Thu, May 07, 2009 at 03:34:58PM -0700, Adam Langley wrote:
> > > That assessment is incorrect, there's no difference between safety
> > > here really.
> > >
> > > LSM cannot magically inspect user-space memory either when multiple
> > > threads may access it. The point would be to define filters for
> > > system call _arguments_, which are inherently thread-local and safe.
> > 
> > If I hook security_operations.socket_connect, I can validate the struct
> > sockaddr after the final copy_from_user. However, since the sockaddr lives in
> > userspace memory, if I try and validate it from ftrace SYSCALL_ENTER, I can't
> > know that it won't change before sys_connect reads it again.
> > 
> > Because of that, there are system calls which an LSM hook can safely accept
> > that an ftrace hook cannot. However, as you point out, any arguments passed in
> > registers are inheriently safe and these may be sufficiently powerful.
> > 
> > > There are two problems with the bitmap scheme, which i also
> > > suggested in a previous thread but then found it to be lacking:
> > >
> > > 1) enumeration: you define a bitmap. That will be problematic
> > >   between compat and native 64-bit (both have different syscall
> > >   vectors).
> > 
> > I /think/ it works out, but I've been bitten before with subtle 32/64 bit
> > compat issues and accept that it's a bit ugly.
> > 
> > > 2) flexibility. It's an on/off selection per syscall. With the
> > >   filter we have on, off, or filtered. That's a _whole_ lot more
> > >   flexible.
> > 
> > Absolutely.
> > 
> > Is there a git tree that I can pull this parsing code from?
> > (git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-2.6-trace.git
> > maybe?). I can patch in the seccomp-on-ftrace work and try building the
> > filtering on top of that. I'll see how it turns out anyway.
> 
> 
> Hi,
> 
> The most uptodate one is:
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git
> on the tracing/filters topic.
> 
> See kernel/trace/trace_events_filter.c
> 
> You might want to reuse some current syscall tracing facility.
> An automated resolution table is built on bootime, you can look
> at the end of arch/x86/kernel/ftrace.c
> 
> This table links each syscalls nr to the matching attribute entry of syscall
> in which you can find:
> 
> - parameters names
> - parameters types
> - syscall name
> 
 
I guess it would be easier for seccomp to make use of the filtering and
reuse the syscall tracing facility if we added filtering to the syscall
tracer first.  It would be useful to do for the syscall tracer anyway,
regardless of whether it (or something similar) ended up being used by
seccomp.

Frederic, did you have any plans for that?  If not, I can take a look
when I get the chance...

Tom

> You can look at the hooks in include/linux/syscall.h:
> The sections inside
> #ifdef CONFIG_FTRACE_SYSCALLS
> 
> Well, it's a bit insane to read, so you can also look
> at include/trace/syscall.h and kernel/trace/trace_syscalls.c and
> see how it is used and how it could be reused.
> 
> 
> Thanks,
> Frederic.
> 

--
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