On Fri, Oct 2, 2015 at 3:04 PM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote: > On Fri, Oct 2, 2015 at 3:02 PM, Kees Cook <keescook@xxxxxxxxxxxx> wrote: >> On Fri, Oct 2, 2015 at 2:29 PM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote: >>> On Fri, Oct 2, 2015 at 2:10 PM, Kees Cook <keescook@xxxxxxxxxxxx> wrote: >>>> On Fri, Oct 2, 2015 at 9:27 AM, Tycho Andersen >>>> <tycho.andersen@xxxxxxxxxxxxx> wrote: >>>>> Hi all, >>>>> >>>>> Here's v5 of the seccomp filter c/r set. The individual patch notes have >>>>> changes, but two highlights are: >>>>> >>>>> * This series is now based on http://patchwork.ozlabs.org/patch/525492/ and >>>>> will need to be built with that patch applied. This gets rid of two incorrect >>>>> patches in the previous series and is a nicer API. >>>>> >>>>> * I couldn't figure out a nice way to have SECCOMP_GET_FILTER_FD return the >>>>> same struct file across calls, so we still need a kcmp command. I've narrowed >>>>> the scope of the one being added to only compare seccomp fds. >>>>> >>>>> Thoughts welcome, >>>> >>>> Hi, sorry I've been slow/busy. I'm finally reading through these threads. >>>> >>>> Happy bit: >>>> - avoiding eBPF and just saving the original filters makes things much easier. >>>> >>>> Sad bit: >>>> - inventing a new interface for seccompfds feels like massive overkill to me. >>>> >>>> While Andy has big dreams, we're not presently doing seccompfd >>>> monitoring, etc. There's no driving user for that kind of interface, >>>> and accepting the maintenance burden of it only for CRIU seems unwise. >>>> >>>> So, I'll go back to what I originally proposed at LSS (which it looks >>>> like we're half way there now): >>>> >>>> - save the original filter (done!) >>>> - extract filters through a single special-purpose interface (looks >>>> like ptrace is the way to go: root-only, stopped process, etc) >>>> - compare filter content and issue TSYNCs to merge detected sibling >>>> threads, since merging things that weren't merged before creates no >>>> problems. >>>> >>>> This means the parenting logic is heuristic, but it's entirely in >>>> userspace, so the complexity burden doesn't live in seccomp which we, >>>> by design, want to keep as simple as possible. >>> >>> This is okay with me with a future-proofing caveat: I think that >>> whatever reads out the filter should be clearly documented as >>> returning some special error code that indicates that that filter it >>> tried to read wasn't in the expected form. That would happen for >>> native eBPF filters, and it would also happen for seccomp monitors >>> even if those monitors use classic BPF. >> >> As in, it should have something like "give me BPF" and that'll start >> failing when it's only eBPF in the future? > > Yes, but it might also start failing when if my dreams come true, it's > still classic BPF, but it's no longer a classic seccomp bpf filter > layer with the semantics we expect today. (E.g. if it's classic bpf > but has a monitor attached, then the read should fail because > restoring it without restoring the monitor will cause all kinds of > mess.) Ah-ha! Understood, and yeah, that seems fine. Speaking of dreams -- what do you think about re-running seccomp in the face of changed syscalls due to ptrace? Closing the ptrace hole would be really nice. -Kees -- Kees Cook Chrome OS Security -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
