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]

Date:   Tue, 27 Feb 2018 08:00:06 -0800
From:   Kees Cook <keescook@...omium.org>
To:     chris hyser <chris.hyser@...cle.com>
Cc:     Andy Lutomirski <luto@...capital.net>,
        Linux Containers <containers@...ts.linux-foundation.org>,
        Netdev <netdev@...r.kernel.org>, Will Drewry <wad@...omium.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        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 Tue, Feb 27, 2018 at 6:53 AM, chris hyser <chris.hyser@...cle.com> wrote:
> 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?

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. ;)

-Kees

-- 
Kees Cook
Pixel Security