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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <db759dd2-31dc-d094-251d-d4c1e8af8704@oracle.com>
Date:   Tue, 27 Feb 2018 09:53:43 -0500
From:   chris hyser <chris.hyser@...cle.com>
To:     Kees Cook <keescook@...omium.org>,
        Andy Lutomirski <luto@...capital.net>,
        containers@...ts.linux-foundation.org,
        Netdev <netdev@...r.kernel.org>
Cc:     Will Drewry <wad@...omium.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Network Development <netdev@...r.kernel.org>,
        Linux Containers <containers@...ts.linux-foundation.org>,
        Alexei Starovoitov <ast@...nel.org>,
        Sargun Dhillon <sargun@...gun.me>,
        Alexei Starovoitov <alexei.starovoitov@...il.com>
Subject: Re: [net-next v3 0/2] eBPF seccomp filters

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