[net-next v3 0/2] eBPF seccomp filters

chris hyser chris.hyser at oracle.com
Tue Feb 27 14:53:43 UTC 2018


On 02/26/2018 11:38 PM, Kees Cook wrote:
> On Mon, Feb 26, 2018 at 8:19 PM, Andy Lutomirski <luto at amacapital.net> 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?

-chrish


More information about the Containers mailing list