On Thu, Apr 17, 2014 at 11:18 AM, Kees Cook <keescook@xxxxxxxxxxxx> wrote: > On Thu, Apr 17, 2014 at 11:13 AM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote: >> On Thu, Apr 17, 2014 at 11:05 AM, Kees Cook <keescook@xxxxxxxxxxxx> wrote: >>> This adds the ability for threads to request seccomp filter >>> synchronization across their thread group. To support this, >>> seccomp locking on writes is introduced, along with refactoring >>> of no_new_privs. Races with thread creation are handled via the >>> tasklist_list. >>> >>> I think all the concerns raised during the discussion[1] of the first >>> version of this patch have been addressed. However, the races involved >>> have tricked me before. :) >>> >> >> Would this be easier to use if there were a single syscall to set a >> seccomp filter and sync threads? That way you wouldn't have to write >> your filter such that it gives permission to sync threads. > > That would be even cleaner, yes. I was hoping to see the new bpf jump > tables before expanding into new filter calls, with the hope of doing > it all at the same time. However, I guess we could just include a > version number in the new call to indicate which filter type it was, > and include flags (like "threadgroup sync") in there? I'm trying to > imagine what would be the least painful for future-proofing. What's the time frame on the new bpf stuff? If it'll be ready for 3.16, it might not matter. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
