Messages in this thread | | | Date | Thu, 7 May 2009 15:34:58 -0700 | Subject | Re: [RFC 1/1] seccomp: Add bitmask of allowed system calls. | From | Adam Langley <> |
| |
> 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.
Thanks
AGL -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |