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: <efedc38e-a29b-478a-0b1b-d8292b793d3c@oracle.com>
Date:   Thu, 1 Mar 2018 01:46:16 -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/28/2018 02:56 PM, Daniel Borkmann wrote:
> On 02/28/2018 12:55 AM, chris hyser wrote:

>> 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 th
>> argument?
> 
> Ok, in addition to the current unpriv restrictions imposed by the verifier,
> what additional requirements would you have from your side in order to get
> to semantics that make sense for you wrt seccomp/eBPF? Just trying to
> understand how far we are away from that. Note that not every new feature,
> map or helper is enabled for every program type of course.

Let me try to clarify my argument by laying out my thoughts here (I apologize if it seems pedantic):

The intent of seccomp is to reduce the kernel attack surfaces available to a compromised user program; if you can't make 
a syscall, you can't exploit some lurking security bug.

Now, if I order various possible seccomp implementation choices in terms of minimizing that implementation's kernel 
attack surfaces it might reasonably be:

1) simple bit vector go/no go check (or similar)
2) cBPF like today
3) some restricted subset of eBPF
4) some other or less restricted subset of eBPF
5) all current eBPF
6) eBPF plus future features

The trade-off is that more features equals less security (ie more security risk). The question is do we allow user land 
to decide where they want to be on that scale or do we pick knowing it will be too much for some and too little for 
others. Answering your question therefore requires knowing either where we choose to be on that scale or what options 
and at what granularity we allow user land to choose. In terms of user land options, just choosing between 2 and 5 might 
be enough. I'd favor say 1 and 4 or 1 and 5 as I don't think it unreasonable for the security paranoid to choose 1.

-chrish