Date:   Tue, 27 Feb 2018 18:55:04 -0500
From:   chris hyser <chris.hyser@...cle.com>
To:     Daniel Borkmann <daniel@...earbox.net>,
        Kees Cook <keescook@...omium.org>
Cc:     Will Drewry <wad@...omium.org>, Netdev <netdev@...r.kernel.org>,
        Linux Containers <containers@...ts.linux-foundation.org>,
        Alexei Starovoitov <ast@...nel.org>,
        Andy Lutomirski <luto@...capital.net>,
        Sargun Dhillon <sargun@...gun.me>,
        Alexei Starovoitov <alexei.starovoitov@...il.com>
Subject: Re: [net-next v3 0/2] eBPF seccomp filters

> On 02/27/2018 04:58 PM, Daniel Borkmann wrote: >> On 02/27/2018 05:59 PM, chris hyser 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
>>
>> Well, not really. One part of all the Spectre mitigations that went upstream
>> from BPF side was to have an option to remove interpreter entirely and that
>> also relates to seccomp eventually. But other than that an attacker might
>> potentially find as well useful gadgets inside seccomp or any other code
>> that is inside the kernel, so it's not a strict necessity either.
>>
>>>>>> 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.
>>
>> Good luck with not breaking existing applications relying on seccomp out
>> there.
> 
> This wasn't in the context of an implementation proposal, but the assumption would be to add this in addition to the old 
> way. Now, does that make sense to do? That is the discussion.
> 
>>
>>>>> 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. ;)
>>
>> Right, agree. cBPF is also pretty much frozen these days and aside from
>> that, seccomp/BPF also just uses a proper subset of it. I wouldn't mind
>> doing something similar for eBPF side as long as this is reasonably
>> maintainable and not making BPF core more complex, but most of it can
>> already be set in the verifier anyway based on prog type. Note, that
>> performance of seccomp/BPF is definitely a demand as well which is why
>> people still extend the old remaining cBPF JITs today such that it can
>> be JITed also from there.
>>
>>> I will try to find that discussion. As someone pointed out here though, eBPF is being used by more and more people in 
>>> areas where security is not the primary concern. Differing objectives will make this a long term continuing issue. We 
>>> ourselves were looking at eBPF simply as a means to use a hashmap for a white/blacklist, i.e. performance not 
>>> flexibility.
>>
>> Not really, security of verifier and BPF infra in general is on the top
>> of the list, it's fundamental to the underlying concept and just because
>> it is heavily used also in tracing and networking, it only shows that the
>> concept is highly flexible that it can be applied in multiple areas.

If you're implying that because seccomp would have it's own verifier and could therefore restrict itself to a subset of 
eBPF, therefore any future additions/features to eBPF would not necessarily make seccomp less secure, I mainly agree. Is 
that the argument?

-chrish

Powered by blists - more mailing lists