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 11:19:12 -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 8:59 AM, chris hyser <chris.hyser@...cle.com> wrote:
> On 02/27/2018 11:00 AM, Kees Cook wrote:
>>
>> 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. ;)
>
>
> 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