On Sat, Sep 05, 2009 at 06:01:58PM +0300, Ali Polatel wrote: > Hey everyone, > I've been writing a ptrace based sandboxing tool, called sydbox¹, and I > want to explain about some of my bad experiences with ptrace and whether > utrace will fix these deficiencies. > > First of all ptrace() makes it rather hard writing portable code that > will work for every architecture. You have to find out registry numbers > for every architecture. It would be really nice if there were a common > interface like utrace_get_syscall(), utrace_set_syscall() that > works for every architecture supported.
Have you looked at using syscall_get_(nr/error/arguments/return_value) et al in arch/<arch>/include/asm/syscall.h > Basically sydbox intercepts some system calls and checks their > arguments. Using ptrace, however, it's not possible to stop the children > only at the entry of system calls we are interested in but we have to > stop them at _every_ system call and check for the system call number. > Because of this threaded applications run very slowly under sydbox as we > have to stop them at every sched_yield(). I know that utrace will split > PTRACE_SYSCALL into two calls SYSCALL_ENTRY and SYSCALL_EXIT and this is > really cool but maybe the ability to stop the children only at system > calls the caller is interested in is a better idea. Utrace engine callbacks happen in the traced task context and as such, are extremely fast. For the case you have, it isn't difficult for your ops->report_syscall_entry to either do a UTRACE_STOP/UTRACE_RESUME depending on what syscall_get_nr() returned. Aside, have you looked at seccomp? The utrace/seccomp branch on the utrace git tree has some work Roland had done earlier to make seccomp use utrace. Ananth
