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