On Tue, Feb 27, 2018 at 8:59 AM, chris hyser <chris.hyser@xxxxxxxxxx> wrote: > On 02/27/2018 11:00 AM, Kees Cook wrote: >> >> On Tue, Feb 27, 2018 at 6:53 AM, chris hyser <chris.hyser@xxxxxxxxxx> >> wrote: >>> >>> On 02/26/2018 11:38 PM, Kees Cook wrote: >>>> >>>> >>>> On Mon, Feb 26, 2018 at 8:19 PM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> >>>> wrote: >>>>> >>>>> >>>>> 3. Straight-up bugs. Those are exactly as problematic as verifier >>>>> bugs in any other unprivileged eBPF program type, right? I don't see >>>>> why seccomp is special here. >>>> >>>> >>>> >>>> My concern is more about unintended design mistakes or other feature >>>> creep with side-effects, especially when it comes to privileges and >>>> synchronization. Getting no-new-privs done correctly, for example, >>>> took some careful thought and discussion, and I'm shy from how painful >>>> TSYNC was on the process locking side, and eBPF has had some rather >>>> ugly flaws in the past (and recently: it was nice to be able to say >>>> for Spectre that seccomp filters couldn't be constructed to make >>>> attacks but eBPF could). Adding the complexity needs to be worth the >>>> gain. I'm on board for doing it, I just want to be careful. :) >>> >>> >>> >>> >>> Another option might be to remove c/eBPF from the equation all together. >>> c/eBPF allows flexibility and that almost always comes at the cost of >>> additional security risk. Seccomp is for enhanced security yes? How about >>> a >>> new seccomp mode that passes in something like a bit vector or hashmap >>> for >>> "simple" white/black list checks validated by kernel code, versus user >>> provided interpreted code? Of course this removes a fair number of things >>> you can currently do or would be able to do with eBPF. Of course, >>> restated >>> from a security point of view, this removes a fair number of things an >>> _attacker_ can do. Presumably the performance improvement would also be >>> significant. >>> >>> Is this an idea worth prototyping? >> >> >> That was the original prototype for seccomp-filter. :) The discussion >> around that from years ago basically boiled down to it being >> inflexible. Given all the things people want to do at syscall time, >> that continues to be true. So true, in fact, that here we are now, >> trying to move to eBPF from cBPF. ;) > > > I will try to find that discussion. As someone pointed out here though, eBPF A good starting point might be this: https://lwn.net/Articles/441232/ -Kees -- Kees Cook Pixel Security _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/containers
